From 39f2114f9797eb51994966c6bb8ff1814c9a4da8 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:36:08 +0100 Subject: unslug fr: move --- "files/fr/web/http/aper\303\247u/index.html" | 178 --------------- .../choisir_entre_les_urls_www_sans_www/index.html | 69 ------ .../index.html | 69 ++++++ .../index.html | 169 --------------- .../identifying_resources_on_the_web/index.html | 169 +++++++++++++++ .../http/basics_of_http/resource_urls/index.html | 67 ++++++ .../urls_de_type_ressource/index.html | 67 ------ .../index.html | 239 +++++++++++++++++++++ files/fr/web/http/cache/index.html | 154 ------------- files/fr/web/http/caching/index.html | 154 +++++++++++++ files/fr/web/http/conditional_requests/index.html | 147 +++++++++++++ .../cors/errors/corsalloworiginmanquant/index.html | 48 ----- .../corsalloworiginnecorrespondpas/index.html | 42 ---- .../corsalloworiginnotmatchingorigin/index.html | 42 ++++ .../web/http/cors/errors/corsdesactive/index.html | 30 --- .../http/cors/errors/corsdidnotsucceed/index.html | 34 +++ .../web/http/cors/errors/corsdisabled/index.html | 30 +++ .../cors/errors/corsmissingalloworigin/index.html | 48 +++++ .../cors/errors/corsnapasr\303\251ussi/index.html" | 34 --- .../index.html | 239 --------------------- .../index.html" | 134 ------------ files/fr/web/http/headers/server/index.html | 72 +++++++ files/fr/web/http/headers/serveur/index.html | 72 ------- files/fr/web/http/link_prefetching_faq/index.html | 134 ++++++++++++ files/fr/web/http/methods/connect/index.html | 86 ++++++++ files/fr/web/http/methods/delete/index.html | 93 ++++++++ files/fr/web/http/methods/get/index.html | 73 +++++++ files/fr/web/http/methods/head/index.html | 77 +++++++ files/fr/web/http/methods/index.html | 73 +++++++ files/fr/web/http/methods/options/index.html | 124 +++++++++++ files/fr/web/http/methods/patch/index.html | 89 ++++++++ files/fr/web/http/methods/post/index.html | 119 ++++++++++ files/fr/web/http/methods/put/index.html | 95 ++++++++ files/fr/web/http/methods/trace/index.html | 77 +++++++ .../fr/web/http/m\303\251thode/connect/index.html" | 86 -------- .../fr/web/http/m\303\251thode/delete/index.html" | 93 -------- "files/fr/web/http/m\303\251thode/get/index.html" | 73 ------- "files/fr/web/http/m\303\251thode/head/index.html" | 77 ------- "files/fr/web/http/m\303\251thode/index.html" | 73 ------- .../fr/web/http/m\303\251thode/options/index.html" | 124 ----------- .../fr/web/http/m\303\251thode/patch/index.html" | 89 -------- "files/fr/web/http/m\303\251thode/post/index.html" | 119 ---------- "files/fr/web/http/m\303\251thode/put/index.html" | 95 -------- .../fr/web/http/m\303\251thode/trace/index.html" | 77 ------- files/fr/web/http/overview/index.html | 178 +++++++++++++++ files/fr/web/http/public_key_pinning/index.html | 170 +++++++++++++++ .../requ\303\252tes_conditionnelles/index.html" | 147 ------------- 47 files changed, 2459 insertions(+), 2289 deletions(-) delete mode 100644 "files/fr/web/http/aper\303\247u/index.html" delete mode 100644 files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html create mode 100644 files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html delete mode 100644 files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html create mode 100644 files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html create mode 100644 files/fr/web/http/basics_of_http/resource_urls/index.html delete mode 100644 files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html create mode 100644 files/fr/web/http/browser_detection_using_the_user_agent/index.html delete mode 100644 files/fr/web/http/cache/index.html create mode 100644 files/fr/web/http/caching/index.html create mode 100644 files/fr/web/http/conditional_requests/index.html delete mode 100644 files/fr/web/http/cors/errors/corsalloworiginmanquant/index.html delete mode 100644 files/fr/web/http/cors/errors/corsalloworiginnecorrespondpas/index.html create mode 100644 files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html delete mode 100644 files/fr/web/http/cors/errors/corsdesactive/index.html create mode 100644 files/fr/web/http/cors/errors/corsdidnotsucceed/index.html create mode 100644 files/fr/web/http/cors/errors/corsdisabled/index.html create mode 100644 files/fr/web/http/cors/errors/corsmissingalloworigin/index.html delete mode 100644 "files/fr/web/http/cors/errors/corsnapasr\303\251ussi/index.html" delete mode 100644 files/fr/web/http/detection_du_navigateur_en_utilisant_le_user_agent/index.html delete mode 100644 "files/fr/web/http/faq_sur_le_pr\303\251chargement_des_liens/index.html" create mode 100644 files/fr/web/http/headers/server/index.html delete mode 100644 files/fr/web/http/headers/serveur/index.html create mode 100644 files/fr/web/http/link_prefetching_faq/index.html create mode 100644 files/fr/web/http/methods/connect/index.html create mode 100644 files/fr/web/http/methods/delete/index.html create mode 100644 files/fr/web/http/methods/get/index.html create mode 100644 files/fr/web/http/methods/head/index.html create mode 100644 files/fr/web/http/methods/index.html create mode 100644 files/fr/web/http/methods/options/index.html create mode 100644 files/fr/web/http/methods/patch/index.html create mode 100644 files/fr/web/http/methods/post/index.html create mode 100644 files/fr/web/http/methods/put/index.html create mode 100644 files/fr/web/http/methods/trace/index.html delete mode 100644 "files/fr/web/http/m\303\251thode/connect/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/delete/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/get/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/head/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/options/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/patch/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/post/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/put/index.html" delete mode 100644 "files/fr/web/http/m\303\251thode/trace/index.html" create mode 100644 files/fr/web/http/overview/index.html create mode 100644 files/fr/web/http/public_key_pinning/index.html delete mode 100644 "files/fr/web/http/requ\303\252tes_conditionnelles/index.html" (limited to 'files/fr/web/http') diff --git "a/files/fr/web/http/aper\303\247u/index.html" "b/files/fr/web/http/aper\303\247u/index.html" deleted file mode 100644 index 33d2758ec2..0000000000 --- "a/files/fr/web/http/aper\303\247u/index.html" +++ /dev/null @@ -1,178 +0,0 @@ ---- -title: Un aperçu de HTTP -slug: Web/HTTP/Aperçu -tags: - - Aperçu - - HTML - - HTTP - - WebMechanics -translation_of: Web/HTTP/Overview ---- -
{{HTTPSidebar}}
- -

HTTP est un {{glossary("protocole")}} qui permet de récupérer des ressources telles que des documents HTML. Il est à la base de tout échange de données sur le Web. C'est un protocole de type client-serveur, ce qui signifie que les requêtes sont initiées par le destinataire (qui est généralement un navigateur web). Un document complet est construit à partir de différents sous-documents qui sont récupérés, par exemple du texte, des descriptions de mise en page, des images, des vidéos, des scripts et bien plus.

- -

Un document web se compose de différentes ressources

- -

Les clients et serveurs communiquent par l'échange de messages individuels (en opposition à un flux de données). Les messages envoyés par le client, généralement un navigateur web, sont appelés des requêtes et les messages renvoyés par le serveur sont appelés réponses.

- -

HTTP est un protocole de la couche d'application fonctionnant au-dessus de TCP (pour la couche de transport) et IP (pour la couche réseau). HTTP est en dessous de la couche de présentation. Conçu au début des années 1990, HTTP est un protocole extensible qui a évolué au cours du temps. C'est un protocole de la couche application dont les données transitent via {{glossary("TCP")}} ou à travers une connexion TCP chiffrée avec {{glossary("TLS")}}. En théorie, tout protocole de transport fiable pourrait être utilisé. En raison de son extensibilité, il n'est pas seulement utilisé pour récupérer des documents, mais aussi pour des images, des vidéos ou bien pour renvoyer des contenus vers des serveurs, comme des résultats de formulaires HTML. HTTP peut aussi être utilisé pour récupérer des parties de documents pour mettre à jour à la demande des pages web.

- -

Composants des systèmes basés sur HTTP

- -

HTTP est un protocole client-serveur : les requêtes sont envoyées par une entité : l'agent utilisateur (ou le proxy qui agit au nom de celui-ci). La majorité du temps, l'agent utilisateur est un navigateur web, mais cela peut-être n'importe quoi, un robot qui analyse le Web pour remplir et maintenir l'index d'un moteur de recherche est un exemple d'agent utilisateur.

- -

Chaque requête individuelle est envoyée au serveur, qui la traite et fournit une réponse. Entre cette requête et la réponse se trouve de nombreuses entités qu'on désignera de façon générique sous le terme {{glossary("Proxy", "proxies")}}. Celles-ci exécutent différentes opérations et agissent comme passerelles ou comme {{glossary("Cache", "caches")}} par exemple.

- -

chaîne client serveur

- -

En réalité, il y a plus d'un ordinateur entre un navigateur et le serveur qui traite la requête : il y a les routeurs, les modems et bien plus. Grâce à la construction en couche du Web, ces intermédiaires sont cachés dans les couches réseau et transport. HTTP est bâti sur la couche applicative. Bien qu'elles puissent s'avérer importantes lorsqu'il s'agit de diagnostiquer des problèmes réseau, les couches inférieures ne sont pas pertinentes ici pour décrire HTTP.

- -

Le client : l'agent  utilisateur

- -

L'agent utilisateur correspond à n'importe quel outil qui agit pour le compte de l'utilisateur. Ce rôle est principalement rempli par le navigateur web ; les exceptions étant les programmes utilisés par des ingénieurs et développeurs web pour le débogage de leurs applications.

- -

Le navigateur est toujours celui qui initie la requête. Il ne s'agit jamais du serveur (bien que certains mécanismes aient été ajoutés au cours des années afin de simuler les messages initiés par un serveur).

- -

Pour afficher une page web, le navigateur envoie une requête initiale pour récupérer le document HTML depuis la page. Ensuite, il analyse le fichier et récupère les requêtes additionnelles qui correspondent aux scripts, aux informations de mise en page (CSS) et les sous-ressources contenues dans la page (généralement des images et des vidéos). Le navigateur web assemble alors ces ressources pour présenter un document complet à l'utilisateur : c'est la page web. Les scripts exécutés par le navigateur peuvent permettre de récupérer plus de ressources par la suite afin de mettre à jour la page web.

- -

Une page web est un document hypertexte. Cela signifie que certaines parties sont des liens qui peuvent être activés (généralement avec un clic de souris) afin de récupérer une nouvelle page web, permettant à l'utilisateur de diriger son agent utilisateur et de naviguer sur le Web. Le navigateur traduit ces instructions en requêtes HTTP et interprète les réponses HTTP pour présenter une réponse claire à l'utilisateur.

- -

Le serveur web

- -

De l'autre côté du canal de communication, on trouve le serveur qui sert le document demandé par le client. Bien qu'on présente virtuellement le serveur comme un seul ordinateur, en réalité, il peut s'agir d'un ensemble de serveurs se répartissant la charge (load balancing) ou d'une architecture logicielle complexe qui interroge d'autres serveurs (par exemple un cache, un serveur de base de données, serveur d'e-commerce…), qui génèrent totalement ou partiellement le document à la demande.

- -

D'une part, un serveur n'est pas nécessairement une machine unique et d'autre part, plusieurs serveurs peuvent être hébergés sur une même machine. Avec HTTP/1.1 et l'en-tête {{HTTPHeader("Host")}}, ils peuvent également partager la même adresse IP.

- -

Les proxys

- -

Entre le navigateur Web et le serveur, de nombreux ordinateurs et machines relaient les messages HTTP. En raison de la structure en couches superposées des technologies web, la plupart des opérations  au niveau du transport, du réseau ou au niveau physique sont transparents pour la couche HTTP, ce qui peut avoir un impact significatif sur les performances. Les opérations au niveau de la couche applicative sont généralement appelées proxy. Ceux-ci peuvent être transparents ou non (en changeant les requêtes qui passent par eux), et peuvent effectuer de nombreuses tâches :

- - - -

Principaux aspects d'HTTP

- -

HTTP est simple

- -

Même s'il est devenu plus complexe avec l'arrivée d'HTTP/2 et l'encapsulation des messages HTTP dans des trames, HTTP est généralement conçu pour être simple et lisible par un humain. Les messages HTTP peuvent être lus et compris par des humains, ce qui facilite les tests des développeurs et réduit la complexité pour les débutants.

- -

HTTP est extensible

- -

À partir de HTTP/1.0, les en-têtes HTTP permettent d'étendre facilement le protocole et de mener des expérimentations avec celui-ci. De nouvelles fonctionnalités peuvent même être introduites par un simple accord entre le client et le serveur à propos de la sémantique des nouveaux en-têtes.

- -

HTTP est sans état, mais pas sans session

- -

HTTP est sans état : il n'y a pas de lien entre deux requêtes qui sont effectuées successivement sur la même connexion. Cela devient très rapidement problématique lorsque les utilisateurs veulent interagir avec une page de façon cohérente, par exemple avec un panier d'achat sur un site de commerce en ligne. Bien que le cœur d'HTTP soit sans état, les cookies HTTP permettent l'utilisation de sessions avec des états. En utilisant l'extensibilité par les en-têtes, des cookies HTTP sont ajoutés aux flux et permettent la création d'une session sur chaque requête HTTP pour partager un même contexte, ou un même état.

- -

HTTP et les connexions

- -

Une connexion est contrôlée au niveau de la couche transport et est donc fondamentalement hors de portée d'HTTP. Bien que HTTP ne nécessite pas un protocole de transport basé sur une connexion. Le protocole doit être fiable ou empêcher la perte de messages (donc gérer au minimum la remontée des erreurs). Parmi les deux protocoles de transport les plus courants sur Internet, TCP est fiable et UDP ne l'est pas. HTTP s'appuie sur le standard TCP, qui est basé sur la connexion, même si une connexion n'est pas toujours nécessaire.

- -

HTTP/1.0 ouvre une connexion TCP pour chaque échange requête/réponse, ce qui introduit deux défauts majeur : l'ouverture d'une connexion nécessite plusieurs allers-retours, ce qui est lent mais devient plus efficace lorsque plusieurs messages sont envoyés et envoyés régulièrement. On dit aussi que les connexions qui restent chaudes sont plus efficaces que les communications froides.

- -

Afin de réduire ces défauts, HTTP/1.1 introduit le pipelining (qui s'est avéré difficile à mettre en œuvre) et les connexions persistantes : la connexion TCP sous-jacente peut être partiellement contrôlée en utilisant l'en-tête {{HTTPHeader("Connection")}}. HTTP/2 va plus loin en multiplexant des messages sur une seule connexion, ce qui aide à maintenir la connexion chaude et plus efficace

- -

Des expérimentations sont en cours afin de concevoir un protocole de transport plus adapté pour HTTP. Par exemple, Google expérimente QUIC, construit sur UDP pour fournir un protocole de transport plus fiable et efficace.

- -

Ce qui peut être contrôlé par HTTP

- -

Au fil du temps, la nature extensible de HTTP a permis de mieux contrôler le Web et d'y ajouter de nouvelles fonctionnalités. Les méthodes de cache ou d'authentification sont des fonctions qui furent gérées dès le début de HTTP tandis que la possibilité de lever la contrainte d'unicité de l'origine ne fut introduite qu'à partir des années 2010.

- -

Voici une liste de fonctionnalités courantes, qui peuvent être contrôlées grâce à HTTP.

- - - -

Flux HTTP

- -

Lorsqu'un client veut communiquer avec un serveur, que ce soit avec un serveur final ou un proxy intermédiaire, il réalise les étapes suivantes :

- -
    -
  1. Il ouvre une connexion TCP : la connexion TCP va être utilisée pour envoyer une ou plusieurs requêtes et pour recevoir une réponse. Le client peut ouvrir une nouvelle connexion, réutiliser une connexion existante ou ouvrir plusieurs connexions TCP vers le serveur.
    2. -
  2. Il envoie un message HTTP : les messages HTTP (avant HTTP/2) sont lisibles par les humains. Avec HTTP/2, ces simples messages sont en-capsulés dans des trames, rendant la lecture directe impossible, mais le principe reste le même. - 
    GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
    -
    3. -
  3. Il lit la réponse envoyée par le serveur : - 
    HTTP/1.1 200 OK
-Date: Sat, 09 Oct 2010 14:28:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
-ETag: "51142bc1-7449-479b075b2891b"
-Accept-Ranges: bytes
-Content-Length: 29769
-Content-Type: text/html
-
-<!DOCTYPE html... (suivi des 29769 octets de la page web demandée)
    -
    4. -
  4. Il ferme ou réutilise la connexion pour les requêtes suivantes.
    5. -
- -

Si le pipeline HTTP est activé, plusieurs demandes peuvent être envoyées sans attendre que la première réponse soit entièrement reçue. Le pipeline HTTP s'est révélé difficile à implémenter dans les réseaux existants où de vieux logiciels coexistent avec des versions modernes. Le pipeline HTTP a été remplacé dans HTTP/2 par des requêtes de multiplexage plus robustes dans les trames.

- -

Les messages HTTP

- -

Les messages HTTP/1.1 et ceux des versions précédentes d'HTTP sont lisibles par des humains. Avec HTTP/2, ces messages sont intégrés dans une nouvelle structure binaire, une trame, ce qui permet des optimisations telles que la compression des en-têtes et le multiplexage. Même si seule une partie du message HTTP d'origine est envoyée dans cette version d'HTTP, la sémantique de chaque message est inchangée et le client reconstitue (virtuellement) la requête HTTP/1.1 d'origine. Il est donc utile de comprendre les messages HTTP/2 au format HTTP/1.1.

- -

Il existe deux types de messages HTTP, les requêtes et les réponses, chacun ayant son propre format.

- -

Requêtes

- -

Un exemple de requête HTTP :

- -

Une requête HTTP basique

- -

Une requête comprend les éléments suivants :

- - - -

Réponses

- -

Un exemple de réponse :

- -

une réponse HTTP

- -

Une réponse comprend les éléments suivants:

- - - -

Les APIs basées sur HTTP

- -

L'API la plus utilisée se basant sur HTTP est l'API {{domxref("XMLHttpRequest")}} qui permet d'échanger des données entre un agent utilisateur {{Glossary("user agent")}} et un serveur.

- -

Une autre API, server-sent events, est un service unidirectionnel permettant à un serveur d'envoyer des notifications au client, en se basant sur le protocole HTTP. À l'aide de l'utilisation de l'interface {{domxref("EventSource")}}, le client ouvre une connexion et initie un gestionnaire d'évènements. Le navigateur convertit alors automatiquement les messages du flux HTTP en objets de type {{domxref("Event")}}, pour ensuite les déléguer au gestionnaire d'évènements qui se sont abonnés à ce {{domxref("Event.type", "type")}} d'évènement. Dans le cas où le type est inconnu ou si aucun gestionnaire typé n'a été défini, ils sont délivrés au gestionnaire d'évènements {{domxref("EventSource.onmessage", "onmessage")}}.

- -

Conclusion

- -

HTTP est un protocole extensible, facile d'utilisation. La structure client-serveur, combinée avec la possibilité d'ajouter simplement des en-têtes, permet à HTTP de progresser au fur et mesure de l'ajout de nouvelles fonctionnalités sur le Web.

- -

Bien que HTTP/2 ajoute de la complexité, en englobant les messages HTTP dans des trames pour améliorer les performances, la structure de base des messages est restée la même depuis HTTP/1.0. Le flux de session reste simple, ce qui lui permet d'être étudié et débogué avec un simple moniteur de message HTTP.

diff --git a/files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html b/files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html deleted file mode 100644 index fe94d1e4c9..0000000000 --- a/files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Choisir entre les URLs avec ou sans www -slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www -tags: - - Guide - - HTTP - - URL -translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs ---- -
{{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.

- -

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.

- -

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 ?

- - - -

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

- -

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

- -

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.

- -

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

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

- - - -

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 :

- -

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

- -

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.

- -

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.

- -

Voir aussi

- - diff --git a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html new file mode 100644 index 0000000000..fe94d1e4c9 --- /dev/null +++ b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html @@ -0,0 +1,69 @@ +--- +title: Choisir entre les URLs avec ou sans www +slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www +tags: + - Guide + - HTTP + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +--- +
{{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.

+ +

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.

+ +

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 ?

+ + + +

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

+ +

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

+ +

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.

+ +

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

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

+ + + +

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 :

+ +

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

+ +

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.

+ +

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.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html b/files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html deleted file mode 100644 index 0265a81829..0000000000 --- a/files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: Identifier des ressources sur le Web -slug: Web/HTTP/Basics_of_HTTP/Identifier_des_ressources_sur_le_Web -tags: - - HTTP -translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_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 :

- - - -

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

Requête

- -
-
Paramètre
-
?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

- - diff --git a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html new file mode 100644 index 0000000000..0265a81829 --- /dev/null +++ b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html @@ -0,0 +1,169 @@ +--- +title: Identifier des ressources sur le Web +slug: Web/HTTP/Basics_of_HTTP/Identifier_des_ressources_sur_le_Web +tags: + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_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 :

+ + + +

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

Requête

+ +
+
Paramètre
+
?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

+ + diff --git a/files/fr/web/http/basics_of_http/resource_urls/index.html b/files/fr/web/http/basics_of_http/resource_urls/index.html new file mode 100644 index 0000000000..4f38214e57 --- /dev/null +++ b/files/fr/web/http/basics_of_http/resource_urls/index.html @@ -0,0 +1,67 @@ +--- +title: URLs de type ressource +slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource +tags: + - Guide + - HTTP + - Intermédiaire + - Ressource +translation_of: Web/HTTP/Basics_of_HTTP/Resource_URLs +--- +
{{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.

+ +

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 :

+ +
resource://<url>
+ +

Voici un exemple :

+ +
resource://gre/res/svg.css
+ +

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

+ +

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

+ +

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

+ +

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.

+ +

Le fichier firefox.js 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.

+ +

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

+ +

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.

+ +

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.

+
+ +

Spécifications

+ +

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

+ +

Compatibilité des navigateurs

+ +

resource: est disponible uniquement dans Firefox.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html b/files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html deleted file mode 100644 index 4f38214e57..0000000000 --- a/files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: URLs de type ressource -slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource -tags: - - Guide - - HTTP - - Intermédiaire - - Ressource -translation_of: Web/HTTP/Basics_of_HTTP/Resource_URLs ---- -
{{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.

- -

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 :

- -
resource://<url>
- -

Voici un exemple :

- -
resource://gre/res/svg.css
- -

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

- -

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

- -

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

- -

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.

- -

Le fichier firefox.js 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.

- -

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

- -

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.

- -

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.

-
- -

Spécifications

- -

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

- -

Compatibilité des navigateurs

- -

resource: est disponible uniquement dans Firefox.

- -

Voir aussi

- - diff --git a/files/fr/web/http/browser_detection_using_the_user_agent/index.html b/files/fr/web/http/browser_detection_using_the_user_agent/index.html new file mode 100644 index 0000000000..bd7a98de65 --- /dev/null +++ b/files/fr/web/http/browser_detection_using_the_user_agent/index.html @@ -0,0 +1,239 @@ +--- +title: Détection du navigateur à l'aide du User-Agent +slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent +tags: + - Compatibilité + - Développement Web +translation_of: Web/HTTP/Browser_detection_using_the_user_agent +--- +
{{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.

+ +

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

+ +
+

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

+
+ +

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.

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

+ +

Il existe des options possibles à considérer pour éviter d'avoir à 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.
+
+ +

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

+ +

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

+ +

Nom du navigateur

+ +

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.

+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 Doit contenirNe doit pas contenir 
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 [1]

+ +

Opera/xyz [2]

+ 		  +

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

+ +

[2] 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).

+ +

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.

+ +

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

+ +

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.

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

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

+ +

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

+ +

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

+ +

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.

+ + + +

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

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

diff --git a/files/fr/web/http/cache/index.html b/files/fr/web/http/cache/index.html deleted file mode 100644 index d29e51d434..0000000000 --- a/files/fr/web/http/cache/index.html +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: Mise en cache HTTP -slug: Web/HTTP/Cache -tags: - - Guide - - HTTP - - Le cache -translation_of: Web/HTTP/Caching ---- -
{{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.

- -

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.

- -

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.

- -

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.

- -

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.

- -

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 :

- - - -

Une entrée de cache peut aussi consister en de multiples réponses stockées différenciées par une clé secondaire, si la requête fait l’objet de négociation de contenu. Pour plus de détails, voir les informations à propos de l’en-tête {{HTTPHeader("Vary")}} ci-dessous.

- -

Contrôle de la mise en cache

- -

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.

- -

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.

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

Pas de cache

- -

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

- -
Cache-Control: no-cache
- -

Caches privées et publiques

- -

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

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.

- -

Pour plus de détails, voir aussi la section Freshness ci-dessous..

- -
Cache-Control: max-age=31536000
- -

Validation

- -

Lors de l'utilisation de la directive "must-revalidate", le cache doit vérifier l'état des ressources obsolètes avant de l'utiliser, et celles qui ont expiré ne doivent pas être utilisées. Pour plus de détails, voir la section Validation ci-dessous.

- -
Cache-Control: must-revalidate
- -

L'en-têtePragma

- -

{{HTTPHeader ("Pragma")}} est un en-tête HTTP / 1.0. Il n'est pas spécifié pour les réponses HTTP et ne constitue donc pas un remplacement fiable pour l'en-tête général HTTP / 1.1 Cache-Control, bien qu'il se comporte de la même manière que Cache-Control: no-cache, si le champ d'en-tête Cache-Control est omis dans une requête. Utilisez Pragma uniquement pour une compatibilité ascendante avec les clients HTTP / 1.0.

- -

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.

- -

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.

- -

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 :

- -
expirationTime = responseTime + freshnessLifetime - currentAge
-
- -

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

- -

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.

- -

Les développeurs Web ont inventé une technique que Steve Sounders a appelée revving[1]. Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.

- -

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.

- -

- -

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

- -

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

- -

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

- -

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.

- -

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.

- -

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.

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

- -

Voir aussi

- - diff --git a/files/fr/web/http/caching/index.html b/files/fr/web/http/caching/index.html new file mode 100644 index 0000000000..d29e51d434 --- /dev/null +++ b/files/fr/web/http/caching/index.html @@ -0,0 +1,154 @@ +--- +title: Mise en cache HTTP +slug: Web/HTTP/Cache +tags: + - Guide + - HTTP + - Le cache +translation_of: Web/HTTP/Caching +--- +
{{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.

+ +

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.

+ +

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.

+ +

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.

+ +

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.

+ +

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 :

+ + + +

Une entrée de cache peut aussi consister en de multiples réponses stockées différenciées par une clé secondaire, si la requête fait l’objet de négociation de contenu. Pour plus de détails, voir les informations à propos de l’en-tête {{HTTPHeader("Vary")}} ci-dessous.

+ +

Contrôle de la mise en cache

+ +

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.

+ +

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.

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

Pas de cache

+ +

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

+ +
Cache-Control: no-cache
+ +

Caches privées et publiques

+ +

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

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.

+ +

Pour plus de détails, voir aussi la section Freshness ci-dessous..

+ +
Cache-Control: max-age=31536000
+ +

Validation

+ +

Lors de l'utilisation de la directive "must-revalidate", le cache doit vérifier l'état des ressources obsolètes avant de l'utiliser, et celles qui ont expiré ne doivent pas être utilisées. Pour plus de détails, voir la section Validation ci-dessous.

+ +
Cache-Control: must-revalidate
+ +

L'en-têtePragma

+ +

{{HTTPHeader ("Pragma")}} est un en-tête HTTP / 1.0. Il n'est pas spécifié pour les réponses HTTP et ne constitue donc pas un remplacement fiable pour l'en-tête général HTTP / 1.1 Cache-Control, bien qu'il se comporte de la même manière que Cache-Control: no-cache, si le champ d'en-tête Cache-Control est omis dans une requête. Utilisez Pragma uniquement pour une compatibilité ascendante avec les clients HTTP / 1.0.

+ +

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.

+ +

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.

+ +

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 :

+ +
expirationTime = responseTime + freshnessLifetime - currentAge
+
+ +

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

+ +

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.

+ +

Les développeurs Web ont inventé une technique que Steve Sounders a appelée revving[1]. Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.

+ +

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.

+ +

+ +

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

+ +

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

+ +

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

+ +

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.

+ +

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.

+ +

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.

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

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/conditional_requests/index.html b/files/fr/web/http/conditional_requests/index.html new file mode 100644 index 0000000000..922b07a2fd --- /dev/null +++ b/files/fr/web/http/conditional_requests/index.html @@ -0,0 +1,147 @@ +--- +title: 'HTTP : Requêtes conditionnelles' +slug: Web/HTTP/Requêtes_conditionnelles +tags: + - Guide + - HTTP + - Requêtes Conditionnelles +translation_of: Web/HTTP/Conditional_requests +--- +

{{HTTPSidebar}}

+ +

HTTP a 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 mettre de côté un contrôle inutile pour vérifier l'intégrité d'un document, comme le sommaire d'un téléchargement, ou éviter de perdre des mises à jour quand on télécharge ou modifie un document sur le serveur.

+ +

Principes

+ +

Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique des 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 :

+ + + +

Validateurs

+ +

Toutes les en-têtes conditionnelles 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 car comparer l'ensemble bit à bit n'est pas faisable et pas toujours désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il y en a de deux sortes :

+ + + +

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

+ + + +

La sorte de la vérification est indépendante du validateur utilisé.  {{HTTPHeader("Last-Modified")}} et {{HTTPHeader("ETag")}}  permettent les deux tupes 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

+ +

La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, au bit prés. C'est obligatoire pour certaines en-têtes et le défaut pour les 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 perdu, parfois au détriment de la performance.

+ +

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

+ +

Validation faible

+ +

La validation faible différe de la validation forte car elle considère que deux versions du document ayant le même contenu sont équivalentes. 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 seront évaluées comme étant 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 conditionnelles

+ +

Plusieurs en-têtes HTTP, appelées en-têtes conditionelles, apportent des conditions aux reques. Ce sont :

+ +
+
{{HTTPHeader("If-Match")}}
+
Succés si la {{HTTPHeader("ETag")}} de la ressource distante est égale à une de celles listées dans cette en-tête. Par défaut, à moins que l'etag soit préfixée 'W/', c'est une validation forte. it performs a strong validation.
+
{{HTTPHeader("If-None-Match")}}
+
Succés si la {{HTTPHeader("ETag")}} de la ressource distante est différente de toutes celles listées dans l'en-tête. Par défaut, à moins que l'etag soit préfixée 'W/', c'est une validation forte.
+
{{HTTPHeader("If-Modified-Since")}}
+
Succés si la date {{HTTPHeader("Last-Modified")}} de la ressource distante est plus récente que celle donnée dans l'en-tête.
+
+
{{HTTPHeader("If-Unmodified-Since")}}
+
Succés si la date {{HTTPHeader("Last-Modified")}} de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.
+
{{HTTPHeader("If-Range")}}
+
Similaire à {{HTTPHeader("If-Match")}}, ou {{HTTPHeader("If-Unmodified-Since")}}, mais peut n'avoir qu'une seule etag, ou une date. Si ça ne colle pas, la requête est rejetée et à la place d'un statut de réponse {{HTTPStatus("206")}} Partial Content , un {{HTTPStatus("200")}} OK est envoyé avec la totlité de la ressource.
+
+ +

Cas d'utilisation

+ +

Mise à jour du Cache

+ +

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

+ +

The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled.

+ +

Dans la ressource les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs {{HTTPHeader("Last-Modified")}} et  {{HTTPHeader("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'esst publiée. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête {{HTTPHeader("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 {{HTTPHeader("If-Modified-Since")}} et {{HTTPHeader("If-Match")}}.

+ +

Si la ressource n'a pas changé, le serveur renvoie une réponse {{HTTPStatus("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.

+ +

With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same.

+ +

Si la ressource n'a pas changée, le serveur renvoie juste une réponse  {{HTTPStatus("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.

+ +

In the case where the resource was changed, it is sent back as if the request wasn't conditional.

+ +

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

+ +

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 :

+ +

A download has been stopped and only partial content has been retrieved.

+ +

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

+ +

The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request.

+ +

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 se sert de {{HTTPHeader("If-Modified-Since")}} et de  {{HTTPHeader("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 :

+ +

When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely.

+ +

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

+ +

The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download.

+ +

Cette solution est plus efficace mais légèrement moins flexible puisqu' une etag seulement peut être utilisée 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"

+ +

Une opération commune des applications web est la mise à jour de document distants. C'est trés usuel dans tout système de fichiers ou dans les applications de contrôle de source et 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 {{HTTPMethod("PUT")}}. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.

+ +

Updating a file with a PUT is very simple when concurrency is not involved.

+ +

Cependant, les choses deviennent un peu moins précises dés que l'on parle de simultanéité des comptes. 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 "course des conditions" ({{glossary("race condition")}}) qui conduit à des comportements problématiques difficiles à cerner et à débugger.

+ +

When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!

+ +

Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre client. De toutes façons, les mises à jour perdues et la "course des conditions" sont appelées à disparaître. Nous voulons des résultats prévisibles et être notifiés quand les changements sont rejetés.

+ +

Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (optimistic 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 :

+ +

Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error.

+ +

Ce ci est implémenté par les en-têtes {{HTTPHeader("If-Match")}} ou {{HTTPHeader("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 {{HTTPStatus("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

+ +

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 "course des conditions" si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnelles peuvent être employées : on ajoute {{HTTPHeader("If-None-Match")}} avec la valeur particulière '*', représentant n'importe quelle etag. La requête aboutira seulement si la ressource n'existait pas avant :

+ +

Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it.

+ +

If-None-Match fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieur). Si vous n'êtes pas sûr que le serveur le soit, vous devez d'abord envoyer une requête {{HTTPMethod("HEAD")}} à la ressource pour vérifier.

+ +

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 obligation du webmaster est de configurer le serveur correctement, en paramètrant les bonnes etags : dans certains environnements, c'est un véritable défi. Une fois cela fait, le serveur renverra les requêtes conditionnelles adaptées.

+ +

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

+ +

Dans les deux cas, c'est clair, les requêtes conditionnelles sont une des fonctionnalités essentielles du Web.

diff --git a/files/fr/web/http/cors/errors/corsalloworiginmanquant/index.html b/files/fr/web/http/cors/errors/corsalloworiginmanquant/index.html deleted file mode 100644 index d18a0d1565..0000000000 --- a/files/fr/web/http/cors/errors/corsalloworiginmanquant/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 'Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.' -slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant -translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin ---- -
{{HTTPSidebar}}
- -

Symptomes

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

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.

- -

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 :

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

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

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

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

-
- -

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

- -

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

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

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

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

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsalloworiginnecorrespondpas/index.html b/files/fr/web/http/cors/errors/corsalloworiginnecorrespondpas/index.html deleted file mode 100644 index fcaedad211..0000000000 --- a/files/fr/web/http/cors/errors/corsalloworiginnecorrespondpas/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: >- - Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « - xyz » -slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas -tags: - - CORSAllowOriginNeCorrespondPas - - Dépannage - - Erreur - - Raison - - Sécurité -translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin ---- -
{{HTTPSidebar}}
- -

Symptomes

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

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

- -

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.

- -

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

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

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

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

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html new file mode 100644 index 0000000000..fcaedad211 --- /dev/null +++ b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html @@ -0,0 +1,42 @@ +--- +title: >- + Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « + xyz » +slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas +tags: + - CORSAllowOriginNeCorrespondPas + - Dépannage + - Erreur + - Raison + - Sécurité +translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin +--- +
{{HTTPSidebar}}
+ +

Symptomes

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

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

+ +

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.

+ +

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

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

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

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

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsdesactive/index.html b/files/fr/web/http/cors/errors/corsdesactive/index.html deleted file mode 100644 index d24896db89..0000000000 --- a/files/fr/web/http/cors/errors/corsdesactive/index.html +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 'Raison: CORS désactiver' -slug: Web/HTTP/CORS/Errors/CORSDesactive -tags: - - CORS - - Erreurs - - HTTP - - HTTPS -translation_of: Web/HTTP/CORS/Errors/CORSDisabled ---- -
{{HTTPSidebar}}
- -

Raison

- -
Reason: CORS disabled
-(Raison : CORS désactivé)
- -

Quel est le problème ?

- -

Une requête HTTP nécessitant le {{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. Ainsi, dans ce cas, les demandes CORS échoueront toujours avec cette erreur.

- -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html new file mode 100644 index 0000000000..72a1788f81 --- /dev/null +++ b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html @@ -0,0 +1,34 @@ +--- +title: 'Raison: la requête CORS a échoué' +slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi +tags: + - CORS + - CORSDidNotSucceed + - Cross-Origin + - Erreur + - HTTP + - HTTPS + - Messages + - Raisons + - Sécurité + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +--- +
{{HTTPSidebar}}
+ +

Raison

+ +
Raison: la requête CORS a échoué
+ +

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.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsdisabled/index.html b/files/fr/web/http/cors/errors/corsdisabled/index.html new file mode 100644 index 0000000000..d24896db89 --- /dev/null +++ b/files/fr/web/http/cors/errors/corsdisabled/index.html @@ -0,0 +1,30 @@ +--- +title: 'Raison: CORS désactiver' +slug: Web/HTTP/CORS/Errors/CORSDesactive +tags: + - CORS + - Erreurs + - HTTP + - HTTPS +translation_of: Web/HTTP/CORS/Errors/CORSDisabled +--- +
{{HTTPSidebar}}
+ +

Raison

+ +
Reason: CORS disabled
+(Raison : CORS désactivé)
+ +

Quel est le problème ?

+ +

Une requête HTTP nécessitant le {{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. Ainsi, dans ce cas, les demandes CORS échoueront toujours avec cette erreur.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html new file mode 100644 index 0000000000..d18a0d1565 --- /dev/null +++ b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html @@ -0,0 +1,48 @@ +--- +title: 'Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.' +slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +--- +
{{HTTPSidebar}}
+ +

Symptomes

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

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.

+ +

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 :

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

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

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

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

+
+ +

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

+ +

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

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

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

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

Voir aussi

+ + diff --git "a/files/fr/web/http/cors/errors/corsnapasr\303\251ussi/index.html" "b/files/fr/web/http/cors/errors/corsnapasr\303\251ussi/index.html" deleted file mode 100644 index 72a1788f81..0000000000 --- "a/files/fr/web/http/cors/errors/corsnapasr\303\251ussi/index.html" +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: 'Raison: la requête CORS a échoué' -slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi -tags: - - CORS - - CORSDidNotSucceed - - Cross-Origin - - Erreur - - HTTP - - HTTPS - - Messages - - Raisons - - Sécurité - - console - - troubleshooting -translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed ---- -
{{HTTPSidebar}}
- -

Raison

- -
Raison: la requête CORS a échoué
- -

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.

- -

Voir aussi

- - diff --git a/files/fr/web/http/detection_du_navigateur_en_utilisant_le_user_agent/index.html b/files/fr/web/http/detection_du_navigateur_en_utilisant_le_user_agent/index.html deleted file mode 100644 index bd7a98de65..0000000000 --- a/files/fr/web/http/detection_du_navigateur_en_utilisant_le_user_agent/index.html +++ /dev/null @@ -1,239 +0,0 @@ ---- -title: Détection du navigateur à l'aide du User-Agent -slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent -tags: - - Compatibilité - - Développement Web -translation_of: Web/HTTP/Browser_detection_using_the_user_agent ---- -
{{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.

- -

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

- -
-

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

-
- -

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.

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

- -

Il existe des options possibles à considérer pour éviter d'avoir à 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.
-
- -

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

- -

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

- -

Nom du navigateur

- -

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.

- -

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Doit contenirNe doit pas contenir 
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 [1]

- -

Opera/xyz [2]

- 		  -

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

- -

[2] 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).

- -

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.

- -

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

- -

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.

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

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

- -

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

- -

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

- -

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.

- - - -

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

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

diff --git "a/files/fr/web/http/faq_sur_le_pr\303\251chargement_des_liens/index.html" "b/files/fr/web/http/faq_sur_le_pr\303\251chargement_des_liens/index.html" deleted file mode 100644 index c401133b7f..0000000000 --- "a/files/fr/web/http/faq_sur_le_pr\303\251chargement_des_liens/index.html" +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: FAQ sur le préchargement des liens -slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens -tags: - - Développement_Web - - Gecko - - HTML - - HTTP -translation_of: Web/HTTP/Link_prefetching_FAQ ---- -

Qu’est ce que le préchargement de liens ?

- -

Le préchargement de liens est un mécanisme du navigateur qui utilise le temps disponible du navigateur pour télécharger ou précharger les documents que les utilisateurs pourraient visiter juste après. Une page web fournit un ensemble de cibles à précharger au navigateur. Une fois que le navigateur a fini de charger la page, il commence, de façon transparente, à précharger les documents spécifiés et les emmagasine dans son cache. Quand l’utilisateur visite un de ces documents préchargés, il peut être ressorti rapidement du cache du navigateur.

- -

Le préchargement fonctionne-t-il avec HTTPS ?

- -

À partir de Gecko 1.9.1 (Firefox 3.5), le contenu HTTPS peut être préchargé.

- -

Quelles sont les cibles à précharger ?

- -

Le navigateur cherche soit une balise HTML link, soit un en-tête HTTP Link: avec un type de relation next ou prefetch. Ci-dessous, un exemple d’utilisation de la balise link :

- -
<link rel="prefetch" href="/images/big.jpeg">
-
- -

La même cible à précharger, cette fois avec un en-tête HTTP Link: :

- -
Link: </images/big.jpeg>; rel=prefetch
-
- -

L’en-tête Link: peut également être spécifiée à l’intérieur d’un document HTML en utilisant une balise HTML meta :

- -
<meta http-equiv="Link" content="&lt;/images/big.jpeg&gt;; rel=prefetch">
-
- -

Le format pour l’en-tête Link:est décrit dans le RFC 2068 section 19.6.2.4.

- -
Note : Nous avons intentionnellement pris pour référence une version dépassée de la spécification HTTP/1.1 car la plus récente RFC 2616 ne décrit pas l’en-tête Link:. Bien que les en-têtes Link: ne fassent pas partie du standard révisé, ils sont toujours utilisés en pratique par les serveurs, pour renseigner les feuilles de styles CSS. Donc nous faisons usage de la même fonction ici.
- -

Le navigateur surveille toutes ces cibles et met en attente chaque requête unique qui doit ensuite être préchargée quand le navigateur est disponible. Il peut y avoir de multiples cibles par page, ainsi on peut comprendre l'utilité de précharger de multiples documents. Par exemple, le document suivant peut contenir plusieurs images lourdes.

- -

Quelques exemples en plus, ci-dessous :

- -
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
-<link rel="next" href="2.html">
-
- -

Les balises ancres (<a>) sont-elles préchargées ?

- -

Non, seulement les balises <link> avec une relation de type next ou prefetch sont préchargées. Toutefois, si l'intérêt en est suffisant, on peut étendre le support du préchargement de liens pour inclure le préchargement des balises <a>, lesquelles devront inclure un type de relation next ou prefetch. Cela aiderait probablement les fournisseurs de contenus à éviter le problème du préchargement de liens morts.

- -

Le préchargement de liens est-il respectueux des standards ?

- -

Oui, le préchargement de liens, comme exposé dans ce document, ne viole aucun standard Web existant. En fait, la spécification HTML 4.01 prend explicitement en compte la définition de nouveaux types de relation pour les liens (Section 6.12: types de liens (fr)). Toutefois, le mécanisme exact employé par Mozilla n’est pas encore standardisé. Une ébauche de spécification est en cours.

- -

Comment le temps disponible du navigateur est-il déterminé ?

- -

Dans l’implémentation actuelle (Mozilla 1.2), le temps disponible est déterminé par l’utilisation de l’API nsIWebProgressListener. On attache un écouteur à l’objet de haut-niveau nsIWebProgress ("@mozilla.org/docloaderservice;1"). De celui-ci, on reçoit les notifications de lancement et d’arrêt du document et nous estimons le temps disponible comme étant la période entre l’arrêt du dernier document et le lancement du document suivant. La dernière notification d’arrêt apparaît à peu près lorsque le gestionnaire onLoad se lance pour le document parent. C’est à ce moment que démarrent les requêtes de préchargement. Si une sous-frame contient des cibles à précharger, le préchargement ne commencera que lorsque la frame la plus haute et toutes ses frames filles auront fini de charger.

- -

Que se passe-t-il si je clique sur un lien pendant un préchargement ?

- -

Quand un utilisateur clique sur un lien ou initie toutes sortes de chargements de page, le préchargement des liens s’arrête et les préchargements de cibles sont abandonnés. Si un document préchargé est partiellement stocké, alors il est emmagasiné dans le cache à condition que le serveur envoie un en-tête de réponse de type Accept-Ranges: bytes. Cet en-tête est typiquement généré par les serveurs web quand ils gèrent du contenu statique. Quand l’utilisateur visite réellement un document préchargé, la portion restante est chargée en utilisant une requête HTTP byte-range.

- -

Et si je télécharge quelque chose en tâche de fond ? Le préchargement de liens viendra-t-il en concurrence pour la bande passante ?

- -

Oui et non. Si vous téléchargez quelque chose en utilisant Mozilla, le préchargement de liens sera retardé jusqu'à ce que les téléchargements en arrière-plan soit complets. Par exemple, si vous chargez un groupe de marque-pages (qui ouvre plusieurs onglets), toutes les requêtes de préchargement initiées par une de ces marque-pages ne se lanceront que lorsque tous les onglets auront fini de se charger. Si vous avez lancé une autre application qui utilise le réseau, le préchargement de liens dans Mozilla sera en compétition pour la bande passante, avec l’autre application. C’est un problème que nous espérons régler dans le futur en s’appuyant sur les services du système d’exploitation pour contrôler le temps disponible sur le réseau.

- -

Existe-t-il des restrictions sur ce qui peut être préchargé ?

- -

Oui, uniquement les URL http:// (et, à partir de {{ Gecko("1.9.1") }}, https://) peuvent être préchargées. Les autres protocoles (comme FTP) ne fournissent pas de support suffisamment riche pour la gestion du cache côté client. En plus de cette restriction, les URL ayant une chaîne de paramètres ne sont pas préchargées. Ceci parce que de telles URL sont souvent dans des documents qui ne peuvent pas être réutilisés en dehors du cache du navigateur. Donc précharger de telles URL n’apporterait pas grand chose. Nous avons constaté que des sites existants utilisent la balise <link rel="next"> avec des URL contenant des chaînes de paramètres pour référencer le document suivant dans une série de documents. Bugzilla est un de ces sites et il s'avère que les rapports de bug dans Bugzilla ne peuvent être mis en cache, aussi précharger ces URL reviendrait à peu près à doubler la charge de ce pauvre Bugzilla ! On peut se douter que d’autres sites ont été conçus comme Bugzilla donc on ne fait explicitement pas de préchargement d’URL contenant des chaînes de paramètres. (Il pourrait être sensé d’autoriser le préchargement de ces documents avec une relation de type rel=prefetch, puisque cela n'apparait pas dans aucun contenu existant). Il n’y a pas d’autres restrictions en ce qui concerne les URL préchargées.

- -

Mozilla peut-il précharger un document d’un hôte différent ?

- -

Oui. Il n’est pas nécessaire que les documents aient la même origine pour le préchargement de liens. Limiter le préchargement uniquement à des URL du même serveur n’augmenterait pas la sécurité du navigateur.

- -

Les requêtes préchargées contiennent-elles un en-tête Referer: ?

- -

Oui, les requêtes préchargées incluent une entête HTTP Referer: qui indique le document duquel la cible de préchargement a été extraite.

- -

Cela peut impacter l'analyse de l'affluence qui est communément utilisée sur de nombreux sites. Pour cette raison, le préchargement de liens peut ne pas être approprié pour toutes sortes de contenus. Toutefois, il est possible de contraindre Mozilla à valider un document préchargé quand l'utilisateur suit un href vers le document préchargé en spécifiant un en-tête de réponse HTTP Cache-control: must-revalidate. Cet en-tête permet la mise en cache mais requiert une requête de validation If-Modified-Since ou If-None-Match pour que le document soit servi à partir du cache du navigateur.

- -

En tant qu'administrateur serveur, puis-je distinguer les requêtes préchargées, des requêtes normales ?

- -

Oui, l'en-tête suivant est envoyé avec chaque requête préchargée :

- -
 X-moz: prefetch
-
- -

Bien sûr, cet en-tête de requête n'est absolument pas standardisé et il peut changer dans les futures versions de Mozilla.

- -

Existe-t-il une préférence pour désactiver le préchargement de liens ?

- -

Oui, il existe une préférence cachée pour désactiver le préchargement de liens. Ajoutez cette ligne dans votre fichier prefs.js qui se trouve dans votre répertoire de profil (ou faite le changement approprié via about:config) :

- -
 user_pref("network.prefetch-next", false);
-
- -

Toutefois, la théorie est que si le préchargement de liens a besoin d'être désactivé c'est qu'il doit y avoir un problème dans l'implémentation. On doit améliorer l'implémentation si ça ne marche pas correctement plutôt que d'attendre que l'utilisateur trouve et modifie une obscure préférence.

- -

Et pour les gens qui payent à la bande passante utilisée ?

- -

En fait, il y a deux façons d'aborder ce problème :

- -
    -
  1. Les sites Web peuvent provoquer le chargement de choses de façon transparente en utilisant des hacks JS/DOM.
    2. -
  2. Le préchargement est une fonctionnalité du navigateur, les utilisateurs devraient pouvoir le désactiver facilement.
    3. -
- -

Il est important que les sites web adoptent la balise <link> pour le préchargement, plutôt que d'essayer d'initier le chargement en tâche de fond avec des hacks JS/DOM. La balise <link> donne au navigateur la capacité de savoir quels sites sont à charger et on peut utiliser cette information pour améliorer le système de priorité du préchargement des liens. La préférence utilisateur pour désactiver le préchargement par la balise <link> encourage simplement les sites Web à s'abstenir d'utiliser des hacks JS/DOM. Cela n'apporterait rien de positif aux utilisateurs. C'est une des raisons pour lesquelles le préchargement est activé par défaut.

- -

Quels navigateurs supportent le préchargement de liens ?

- -

Les navigateurs basés sur Mozilla 1.2 (ou +) aussi bien que ceux basés sur Mozilla 1.0.2 (ou +) supportent le préchargement. Cela inclut Firefox et Netscape 7.02+. Les compilations Camino, en Mars 2003, sont basées sur Mozilla 1.0.1 et donc ne supportent pas le préchargement. Testez votre navigateur pour vérifier s'il supporte le préchargement de liens.

- -

D'autres questions ?

- -

Si vous avez des questions ou des commentaires sur le préchargement de liens, n'hésitez pas à me les envoyer :-)

- -

Voir également

- - - -
-

Informations sur le document original

- - -
- -

{{ languages( { "en": "en/Link_prefetching_FAQ", "it": "it/Link_prefetching_FAQ", "ja": "ja/Link_prefetching_FAQ" } ) }}

diff --git a/files/fr/web/http/headers/server/index.html b/files/fr/web/http/headers/server/index.html new file mode 100644 index 0000000000..d5712fc7ac --- /dev/null +++ b/files/fr/web/http/headers/server/index.html @@ -0,0 +1,72 @@ +--- +title: Serveur +slug: Web/HTTP/Headers/Serveur +tags: + - HTTP + - Reference + - header +translation_of: Web/HTTP/Headers/Server +--- +
{{ HTTPSidebar }}
+ +
 
+ +

Le paramètre d'entête Server contient des informations à propos du système (ou sous-système) en place sur le serveur qui s'occupe de la requête.

+ +

Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Server: <valeur>
+
+ +

Directives

+ +
+
<valeur>
+
Le nom du système (ou sous-système) qui gère les requêtes.
+
+ +

Exemples

+ +
Server: Apache/2.4.1 (Unix)
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Server", "7.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ + + + + +

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

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/serveur/index.html b/files/fr/web/http/headers/serveur/index.html deleted file mode 100644 index d5712fc7ac..0000000000 --- a/files/fr/web/http/headers/serveur/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Serveur -slug: Web/HTTP/Headers/Serveur -tags: - - HTTP - - Reference - - header -translation_of: Web/HTTP/Headers/Server ---- -
{{ HTTPSidebar }}
- -
 
- -

Le paramètre d'entête Server contient des informations à propos du système (ou sous-système) en place sur le serveur qui s'occupe de la requête.

- -

Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.

- - - - - - - - - - - - -
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Server: <valeur>
-
- -

Directives

- -
-
<valeur>
-
Le nom du système (ou sous-système) qui gère les requêtes.
-
- -

Exemples

- -
Server: Apache/2.4.1 (Unix)
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Server", "7.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- - - - - -

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

- -

Voir également

- - diff --git a/files/fr/web/http/link_prefetching_faq/index.html b/files/fr/web/http/link_prefetching_faq/index.html new file mode 100644 index 0000000000..c401133b7f --- /dev/null +++ b/files/fr/web/http/link_prefetching_faq/index.html @@ -0,0 +1,134 @@ +--- +title: FAQ sur le préchargement des liens +slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens +tags: + - Développement_Web + - Gecko + - HTML + - HTTP +translation_of: Web/HTTP/Link_prefetching_FAQ +--- +

Qu’est ce que le préchargement de liens ?

+ +

Le préchargement de liens est un mécanisme du navigateur qui utilise le temps disponible du navigateur pour télécharger ou précharger les documents que les utilisateurs pourraient visiter juste après. Une page web fournit un ensemble de cibles à précharger au navigateur. Une fois que le navigateur a fini de charger la page, il commence, de façon transparente, à précharger les documents spécifiés et les emmagasine dans son cache. Quand l’utilisateur visite un de ces documents préchargés, il peut être ressorti rapidement du cache du navigateur.

+ +

Le préchargement fonctionne-t-il avec HTTPS ?

+ +

À partir de Gecko 1.9.1 (Firefox 3.5), le contenu HTTPS peut être préchargé.

+ +

Quelles sont les cibles à précharger ?

+ +

Le navigateur cherche soit une balise HTML link, soit un en-tête HTTP Link: avec un type de relation next ou prefetch. Ci-dessous, un exemple d’utilisation de la balise link :

+ +
<link rel="prefetch" href="/images/big.jpeg">
+
+ +

La même cible à précharger, cette fois avec un en-tête HTTP Link: :

+ +
Link: </images/big.jpeg>; rel=prefetch
+
+ +

L’en-tête Link: peut également être spécifiée à l’intérieur d’un document HTML en utilisant une balise HTML meta :

+ +
<meta http-equiv="Link" content="&lt;/images/big.jpeg&gt;; rel=prefetch">
+
+ +

Le format pour l’en-tête Link:est décrit dans le RFC 2068 section 19.6.2.4.

+ +
Note : Nous avons intentionnellement pris pour référence une version dépassée de la spécification HTTP/1.1 car la plus récente RFC 2616 ne décrit pas l’en-tête Link:. Bien que les en-têtes Link: ne fassent pas partie du standard révisé, ils sont toujours utilisés en pratique par les serveurs, pour renseigner les feuilles de styles CSS. Donc nous faisons usage de la même fonction ici.
+ +

Le navigateur surveille toutes ces cibles et met en attente chaque requête unique qui doit ensuite être préchargée quand le navigateur est disponible. Il peut y avoir de multiples cibles par page, ainsi on peut comprendre l'utilité de précharger de multiples documents. Par exemple, le document suivant peut contenir plusieurs images lourdes.

+ +

Quelques exemples en plus, ci-dessous :

+ +
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
+<link rel="next" href="2.html">
+
+ +

Les balises ancres (<a>) sont-elles préchargées ?

+ +

Non, seulement les balises <link> avec une relation de type next ou prefetch sont préchargées. Toutefois, si l'intérêt en est suffisant, on peut étendre le support du préchargement de liens pour inclure le préchargement des balises <a>, lesquelles devront inclure un type de relation next ou prefetch. Cela aiderait probablement les fournisseurs de contenus à éviter le problème du préchargement de liens morts.

+ +

Le préchargement de liens est-il respectueux des standards ?

+ +

Oui, le préchargement de liens, comme exposé dans ce document, ne viole aucun standard Web existant. En fait, la spécification HTML 4.01 prend explicitement en compte la définition de nouveaux types de relation pour les liens (Section 6.12: types de liens (fr)). Toutefois, le mécanisme exact employé par Mozilla n’est pas encore standardisé. Une ébauche de spécification est en cours.

+ +

Comment le temps disponible du navigateur est-il déterminé ?

+ +

Dans l’implémentation actuelle (Mozilla 1.2), le temps disponible est déterminé par l’utilisation de l’API nsIWebProgressListener. On attache un écouteur à l’objet de haut-niveau nsIWebProgress ("@mozilla.org/docloaderservice;1"). De celui-ci, on reçoit les notifications de lancement et d’arrêt du document et nous estimons le temps disponible comme étant la période entre l’arrêt du dernier document et le lancement du document suivant. La dernière notification d’arrêt apparaît à peu près lorsque le gestionnaire onLoad se lance pour le document parent. C’est à ce moment que démarrent les requêtes de préchargement. Si une sous-frame contient des cibles à précharger, le préchargement ne commencera que lorsque la frame la plus haute et toutes ses frames filles auront fini de charger.

+ +

Que se passe-t-il si je clique sur un lien pendant un préchargement ?

+ +

Quand un utilisateur clique sur un lien ou initie toutes sortes de chargements de page, le préchargement des liens s’arrête et les préchargements de cibles sont abandonnés. Si un document préchargé est partiellement stocké, alors il est emmagasiné dans le cache à condition que le serveur envoie un en-tête de réponse de type Accept-Ranges: bytes. Cet en-tête est typiquement généré par les serveurs web quand ils gèrent du contenu statique. Quand l’utilisateur visite réellement un document préchargé, la portion restante est chargée en utilisant une requête HTTP byte-range.

+ +

Et si je télécharge quelque chose en tâche de fond ? Le préchargement de liens viendra-t-il en concurrence pour la bande passante ?

+ +

Oui et non. Si vous téléchargez quelque chose en utilisant Mozilla, le préchargement de liens sera retardé jusqu'à ce que les téléchargements en arrière-plan soit complets. Par exemple, si vous chargez un groupe de marque-pages (qui ouvre plusieurs onglets), toutes les requêtes de préchargement initiées par une de ces marque-pages ne se lanceront que lorsque tous les onglets auront fini de se charger. Si vous avez lancé une autre application qui utilise le réseau, le préchargement de liens dans Mozilla sera en compétition pour la bande passante, avec l’autre application. C’est un problème que nous espérons régler dans le futur en s’appuyant sur les services du système d’exploitation pour contrôler le temps disponible sur le réseau.

+ +

Existe-t-il des restrictions sur ce qui peut être préchargé ?

+ +

Oui, uniquement les URL http:// (et, à partir de {{ Gecko("1.9.1") }}, https://) peuvent être préchargées. Les autres protocoles (comme FTP) ne fournissent pas de support suffisamment riche pour la gestion du cache côté client. En plus de cette restriction, les URL ayant une chaîne de paramètres ne sont pas préchargées. Ceci parce que de telles URL sont souvent dans des documents qui ne peuvent pas être réutilisés en dehors du cache du navigateur. Donc précharger de telles URL n’apporterait pas grand chose. Nous avons constaté que des sites existants utilisent la balise <link rel="next"> avec des URL contenant des chaînes de paramètres pour référencer le document suivant dans une série de documents. Bugzilla est un de ces sites et il s'avère que les rapports de bug dans Bugzilla ne peuvent être mis en cache, aussi précharger ces URL reviendrait à peu près à doubler la charge de ce pauvre Bugzilla ! On peut se douter que d’autres sites ont été conçus comme Bugzilla donc on ne fait explicitement pas de préchargement d’URL contenant des chaînes de paramètres. (Il pourrait être sensé d’autoriser le préchargement de ces documents avec une relation de type rel=prefetch, puisque cela n'apparait pas dans aucun contenu existant). Il n’y a pas d’autres restrictions en ce qui concerne les URL préchargées.

+ +

Mozilla peut-il précharger un document d’un hôte différent ?

+ +

Oui. Il n’est pas nécessaire que les documents aient la même origine pour le préchargement de liens. Limiter le préchargement uniquement à des URL du même serveur n’augmenterait pas la sécurité du navigateur.

+ +

Les requêtes préchargées contiennent-elles un en-tête Referer: ?

+ +

Oui, les requêtes préchargées incluent une entête HTTP Referer: qui indique le document duquel la cible de préchargement a été extraite.

+ +

Cela peut impacter l'analyse de l'affluence qui est communément utilisée sur de nombreux sites. Pour cette raison, le préchargement de liens peut ne pas être approprié pour toutes sortes de contenus. Toutefois, il est possible de contraindre Mozilla à valider un document préchargé quand l'utilisateur suit un href vers le document préchargé en spécifiant un en-tête de réponse HTTP Cache-control: must-revalidate. Cet en-tête permet la mise en cache mais requiert une requête de validation If-Modified-Since ou If-None-Match pour que le document soit servi à partir du cache du navigateur.

+ +

En tant qu'administrateur serveur, puis-je distinguer les requêtes préchargées, des requêtes normales ?

+ +

Oui, l'en-tête suivant est envoyé avec chaque requête préchargée :

+ +
 X-moz: prefetch
+
+ +

Bien sûr, cet en-tête de requête n'est absolument pas standardisé et il peut changer dans les futures versions de Mozilla.

+ +

Existe-t-il une préférence pour désactiver le préchargement de liens ?

+ +

Oui, il existe une préférence cachée pour désactiver le préchargement de liens. Ajoutez cette ligne dans votre fichier prefs.js qui se trouve dans votre répertoire de profil (ou faite le changement approprié via about:config) :

+ +
 user_pref("network.prefetch-next", false);
+
+ +

Toutefois, la théorie est que si le préchargement de liens a besoin d'être désactivé c'est qu'il doit y avoir un problème dans l'implémentation. On doit améliorer l'implémentation si ça ne marche pas correctement plutôt que d'attendre que l'utilisateur trouve et modifie une obscure préférence.

+ +

Et pour les gens qui payent à la bande passante utilisée ?

+ +

En fait, il y a deux façons d'aborder ce problème :

+ +
    +
  1. Les sites Web peuvent provoquer le chargement de choses de façon transparente en utilisant des hacks JS/DOM.
    2. +
  2. Le préchargement est une fonctionnalité du navigateur, les utilisateurs devraient pouvoir le désactiver facilement.
    3. +
+ +

Il est important que les sites web adoptent la balise <link> pour le préchargement, plutôt que d'essayer d'initier le chargement en tâche de fond avec des hacks JS/DOM. La balise <link> donne au navigateur la capacité de savoir quels sites sont à charger et on peut utiliser cette information pour améliorer le système de priorité du préchargement des liens. La préférence utilisateur pour désactiver le préchargement par la balise <link> encourage simplement les sites Web à s'abstenir d'utiliser des hacks JS/DOM. Cela n'apporterait rien de positif aux utilisateurs. C'est une des raisons pour lesquelles le préchargement est activé par défaut.

+ +

Quels navigateurs supportent le préchargement de liens ?

+ +

Les navigateurs basés sur Mozilla 1.2 (ou +) aussi bien que ceux basés sur Mozilla 1.0.2 (ou +) supportent le préchargement. Cela inclut Firefox et Netscape 7.02+. Les compilations Camino, en Mars 2003, sont basées sur Mozilla 1.0.1 et donc ne supportent pas le préchargement. Testez votre navigateur pour vérifier s'il supporte le préchargement de liens.

+ +

D'autres questions ?

+ +

Si vous avez des questions ou des commentaires sur le préchargement de liens, n'hésitez pas à me les envoyer :-)

+ +

Voir également

+ + + +
+

Informations sur le document original

+ + +
+ +

{{ languages( { "en": "en/Link_prefetching_FAQ", "it": "it/Link_prefetching_FAQ", "ja": "ja/Link_prefetching_FAQ" } ) }}

diff --git a/files/fr/web/http/methods/connect/index.html b/files/fr/web/http/methods/connect/index.html new file mode 100644 index 0000000000..62b1ee7d6c --- /dev/null +++ b/files/fr/web/http/methods/connect/index.html @@ -0,0 +1,86 @@ +--- +title: CONNECT +slug: Web/HTTP/Méthode/CONNECT +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/CONNECT +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP CONNECT crée une communication bidirectionnelle avec la ressource demandée. Elle peut être utilisée pour ouvrir un tunnel.

+ +

Par exemple, la méthode CONNECT peut être utilisée pour accéder à des sites web qui utilisent {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). Le client demande à un serveur Proxy HTTP de créer un tunnel TCP vers la destination désirée. Le serveur poursuit alors afin d'établir la connexion pour le compte du client. Une fois que la connexion a été établie par le serveur, le serveur Proxy continue de gérer le flux TCP à destination et en provenance du client.

+ +

CONNECT est une méthode "saut-par-saut".

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsOui
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Non
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
CONNECT www.example.com:443 HTTP/1.1
+
+ +

Exemple

+ +

Certains serveurs proxy pourraient avoir besoin d'une autorisation pour créer un tunnel. Voir aussi l'en-tête {{HTTPHeader("Proxy-Authorization")}}.

+ +
CONNECT server.example.com:80 HTTP/1.1
+Host: server.example.com:80
+Proxy-Authorization: basic aGVsbG86d29ybGQ=
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http/methods", "CONNECT")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/delete/index.html b/files/fr/web/http/methods/delete/index.html new file mode 100644 index 0000000000..d2a40a8ea9 --- /dev/null +++ b/files/fr/web/http/methods/delete/index.html @@ -0,0 +1,93 @@ +--- +title: DELETE +slug: Web/HTTP/Méthode/DELETE +tags: + - HTTP + - HTTP method + - Reference + - Request method +translation_of: Web/HTTP/Methods/DELETE +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP DELETE supprime la ressource indiquée.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
DELETE /file.html HTTP/1.1
+
+ +

Exemple

+ +

Requête

+ +
DELETE /file.html HTTP/1.1
+ +

Réponses

+ +

Si une méthode DELETE est appliquée avec succès, il y a plusieurs codes de statut de réponse possibles :

+ + + +
HTTP/1.1 200 OK
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+<html>
+  <body>
+    <h1>File deleted.</h1>
+  </body>
+</html>
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "DELETE", "4.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/get/index.html b/files/fr/web/http/methods/get/index.html new file mode 100644 index 0000000000..008f479d98 --- /dev/null +++ b/files/fr/web/http/methods/get/index.html @@ -0,0 +1,73 @@ +--- +title: GET +slug: Web/HTTP/Méthode/GET +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/GET +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Safe","Sûre")}}Oui
{{Glossary("Idempotent","Idempotente")}}Oui
{{Glossary("Cacheable","Peut être mise en cache")}}Oui
Autorisée dans les formulaires HTMLOui
+ +

Syntaxe

+ +
GET /index.html
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http/methods", "GET")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/head/index.html b/files/fr/web/http/methods/head/index.html new file mode 100644 index 0000000000..f89bbdde39 --- /dev/null +++ b/files/fr/web/http/methods/head/index.html @@ -0,0 +1,77 @@ +--- +title: HEAD +slug: Web/HTTP/Méthode/HEAD +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/HEAD +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP HEAD demande les en-têtes qui seraient retournés si la ressource spécifiée était demandée avec une méthode HTTP {{HTTPMethod("GET")}}. Une telle requête peut être envoyée avant de procéder au téléchargement d'une  ressource volumineuse, par exemple pour économiser de la bande passante.

+ +

Une réponse issue d'une requête HEAD ne doit pas avoir de corps. Si tel est le cas, elle doit être ignorée. Toutefois, les {{glossary("En-têtes d'entité", "en-têtes d'entité")}} décrivant le contenu du corps, comme {{HTTPHeader("Content-Length")}}, peuvent être inclus dans la réponse. Ils ne sont pas liés au corps de la réponse HEAD , qui doit être vide, mais au corps d'une réponse issue d'une requête similaire utilisant la méthode {{HTTPMethod("GET")}}.

+ +

Si le résultat d'une requête HEAD montre qu'une ressource mise en cache après une requête {{HTTPMethod("GET")}} est désormais dépassée, le cache est invalidé, même si aucune requête GET n'a été émise.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Oui
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
HEAD /index.html
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "HEAD", "4.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http/methods", "HEAD")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/index.html b/files/fr/web/http/methods/index.html new file mode 100644 index 0000000000..25ae456c7c --- /dev/null +++ b/files/fr/web/http/methods/index.html @@ -0,0 +1,73 @@ +--- +title: Méthodes de requête HTTP +slug: Web/HTTP/Méthode +tags: + - HTTP + - Méthodes + - Reference +translation_of: Web/HTTP/Methods +--- +
{{HTTPSidebar}}
+ +

HTTP définit un ensemble de méthodes de requête qui indiquent l'action que l'on souhaite réaliser sur la ressource indiquée. Bien qu'on rencontre également des noms (en anglais), ces méthodes sont souvent appelées verbes HTTP. Chacun d'eux implémente une sémantique différente mais certaines fonctionnalités courantes peuvent être partagées par différentes méthodes (e.g. une méthode de requête peut être sûre (safe), idempotente ou être mise en cache (cacheable)).

+ +
+
GET
+
La méthode GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.
+
HEAD
+
La méthode HEAD demande une réponse identique à une requête GET pour laquelle on aura omis le corps de la réponse (on a uniquement l'en-tête).
+
POST
+
La méthode POST est utilisée pour envoyer une entité vers la ressource indiquée. Cela  entraîne généralement un changement d'état ou des effets de bord sur le serveur.
+
PUT
+
+

La méthode PUT remplace toutes les représentations actuelles de la ressource visée par le contenu de la requête.

+
+
DELETE
+
La méthode DELETE supprime la ressource indiquée.
+
CONNECT
+
+

La méthode CONNECT établit un tunnel vers le serveur identifié par la ressource cible.

+
+
OPTIONS
+
La méthode OPTIONS est utilisée pour décrire les options de communications avec la ressource visée.
+
TRACE
+
+

La méthode TRACE réalise un message de test aller/retour en suivant le chemin de la ressource visée.

+
+
PATCH
+
La méthode PATCH est utilisée pour appliquer des modifications partielles à une ressource.
+
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationTitreCommentaires
{{RFC("7231", "Request methods", "4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentDéfinition de GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS et TRACE.
{{RFC("5789", "Patch method", "2")}}PATCH Method for HTTPDéfinition de PATCH.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http/methods")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/options/index.html b/files/fr/web/http/methods/options/index.html new file mode 100644 index 0000000000..ccdd97ef59 --- /dev/null +++ b/files/fr/web/http/methods/options/index.html @@ -0,0 +1,124 @@ +--- +title: OPTIONS +slug: Web/HTTP/Méthode/OPTIONS +translation_of: Web/HTTP/Methods/OPTIONS +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP OPTIONS est utilisée pour décrire les options de communication pour la ressource ciblée. Le client peut renseigner une URL spécifique pour la méthode OPTIONS, ou une astérisque (*) pour interroger le serveur dans sa globalité.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

 

+ +

Syntaxe

+ +
OPTIONS /index.html HTTP/1.1
+OPTIONS * HTTP/1.1
+
+ +

Examples

+ +

Identifier les méthodes HTTP autorisées

+ +

Pour déterminer les méthodes HTTP supportées par le serveur, on peut utiliser curl et envoyer une requête OPTIONS :

+ +
curl -X OPTIONS http://example.org -i
+ +

La réponse contient un en-tête {{HTTPHeader("Allow")}} qui liste les méthodes autorisées :

+ +
HTTP/1.1 200 OK
+Allow: OPTIONS, GET, HEAD, POST
+Cache-Control: max-age=604800
+Date: Thu, 13 Oct 2016 11:45:00 GMT
+Expires: Thu, 20 Oct 2016 11:45:00 GMT
+Server: EOS (lax004/2813)
+x-ec-custom-error: 1
+Content-Length: 0
+
+ +

Requête de pré-vérification cross-origin CORS

+ +

En CORS, une requête de pré-vérification est envoyée avec la méthode OPTIONS afin que le serveur indique si la requête est acceptable avec les paramètres spécifiés. En tant qu'élément de la requête de pré-vérification, le header {{HTTPHeader("Access-Control-Request-Method")}} notifie le serveur que lorsque la véritable requête sera envoyée, ce sera avec une méthode POST. Le header {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que lorsque la vraie requête sera envoyée, elle aura les en-tête personnalisés X-PINGOTHER et Content-Type. Le serveur a maintenant la possibilité de déterminer s'il souhaite ou non accepter la requête dans les conditions énoncées par la requête de pré-vérification.

+ +
OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+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://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+ +

Dans la réponse du serveur, l'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique que les méthodes POST, GET, and OPTIONS sont utilisables pour interroger la ressource.  Cet en-tête est similaire à {{HTTPHeader("Allow")}}, mais utilisé uniquement dans le contexte CORS.

+ +
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://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+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
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "OPTIONS", "4.3.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.methods.OPTIONS")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/patch/index.html b/files/fr/web/http/methods/patch/index.html new file mode 100644 index 0000000000..aca3dfe6d4 --- /dev/null +++ b/files/fr/web/http/methods/patch/index.html @@ -0,0 +1,89 @@ +--- +title: PATCH +slug: Web/HTTP/Méthode/PATCH +translation_of: Web/HTTP/Methods/PATCH +--- +

La méthode PATCH d'une requête HTTP applique des modifications partielles à une ressource.

+ +

La méthode HTTP {{HTTPMethod("PUT")}} est déjà définie pour écraser une ressource avec un nouveau corps complet de message, et pour la méthode HTTP {{HTTPMethod("POST")}}, il n'existe aucun moyen standard pour découvrir le support de format de patch. Tout comme POST, la méthode HTTP PATCH n'est pas listée comme étant idempotent, contrairement à PUT. Cela signifie que les requêtes patch identiques et successives auront des effets différents sur l'objet manipulé.

+ +

Pour découvrir si un serveur supporte la méthode PATCH, un serveur peut annoncer son support en l'ajoutant à la liste des méthodes autorisées dans les headers de la réponse {{HTTPHeader ("Allow")}} ou encore {{HTTPHeader ("Access-Control-Allow-Methods")}} (pour CORS).

+ +

Une autre indication (implicite) que la méthode PATCH est autorisée est la présence du header {{HTTPHeader("Accept-Patch")}}.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête possède un corps de message (body)Oui
Une requête traitée avec succès retourne une réponse avec un corps de message (body)Non
{{Glossary("Safe")}}Non
{{Glossary("Idempotent")}}Non
{{Glossary("Cacheable")}}Non
Utilisation au sein des formulaires HTMLNon
+ +

Syntaxe

+ +
PATCH /file.txt HTTP/1.1
+
+ +

Exemple

+ +

Requête

+ +
PATCH /file.txt HTTP/1.1
+Host: www.example.com
+Content-Type: application/example
+If-Match: "e0023aa4e"
+Content-Length: 100
+
+[description des changements]
+ +

Réponse

+ +

Une requête traitée avec succès retourne une réponse accompagnée d'un code de réponse {{HTTPStatus("204")}}. Dans ce cas-ci, la réponse ne contient un corps de message.

+ +
HTTP/1.1 204 No Content
+Content-Location: /file.txt
+ETag: "e0023aa4f"
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("5789", "PATCH")}}Méthode PATCH pour HTTP (PATCH Method for HTTP)
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/post/index.html b/files/fr/web/http/methods/post/index.html new file mode 100644 index 0000000000..e534246de7 --- /dev/null +++ b/files/fr/web/http/methods/post/index.html @@ -0,0 +1,119 @@ +--- +title: POST +slug: Web/HTTP/Méthode/POST +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/POST +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP POST envoie des données au serveur. Le type du corps de la requête est indiqué par l'en-tête {{HTTPHeader("Content-Type")}}.

+ +

La différence entre PUT et {{HTTPMethod("POST")}} tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

+ +

Une requête POST est habituellement envoyée via un formulaire HTML et a pour résultat un changement sur le serveur. Dans ce cas, le type du contenu est sélectionné en mettant la chaîne de caractères adéquate dans l'attribut {{htmlattrxref("enctype", "form")}} de l'élément {{HTMLElement("form")}} ou dans l'attribut {{htmlattrxref("formenctype", "input")}} de l'élément {{HTMLElement("input") }}, voir celui des éléments {{HTMLElement("button")}} :

+ + + +

Lorsque la requête POST est envoyée par un autre moyen qu'un formulaire HTML, par exemple via {{domxref("XMLHttpRequest")}}, le corps peut être de n'importe quel type. Comme décrit dans la spécification HTTP 1.1, la méthode POST est conçue pour permettre une méthode uniforme couvrant les fonctions suivantes :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsOui
Une réponse inclut un corpsOui
{{Glossary("Safe","Sûre")}}Non
{{Glossary("Idempotent","Idempotente")}}Non
{{Glossary("Cacheable","Peut être mise en cache")}}Seulement si une information de péremption est incluse
Autorisée dans les  formulaires HTMLOui
+ +

Syntaxe

+ +
POST /index.html
+
+ +

Exemple

+ +

Un formulaire simple utilisant le type de contenu par défaut application/x-www-form-urlencoded :

+ +
POST / HTTP/1.1
+Host: foo.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 13
+
+say=Hi&to=Mom
+ +

Un formulaire utilisant le type de contenu multipart/form-data :

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

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.methods.POST")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/put/index.html b/files/fr/web/http/methods/put/index.html new file mode 100644 index 0000000000..d6e7dbeeb7 --- /dev/null +++ b/files/fr/web/http/methods/put/index.html @@ -0,0 +1,95 @@ +--- +title: PUT +slug: Web/HTTP/Méthode/PUT +tags: + - HTTP + - HTTP method + - Reference + - Request method +translation_of: Web/HTTP/Methods/PUT +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP PUT crée une nouvelle ressource ou remplace une représentation de la ressource ciblée par le contenu de la requête.

+ +

La différence entre PUT et POST tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsOui
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
PUT /new.html HTTP/1.1
+
+ +

Exemple

+ +

Requête

+ +
PUT /new.html HTTP/1.1
+Host: example.com
+Content-type: text/html
+Content-length: 16
+
+<p>New File</p>
+ +

Réponses

+ +

Si la ressource ciblée ne possède pas de représentation courante et que la requête PUT en crée une avec succès, alors le serveur d'origine doit informer l'agent utilisateur en envoyant une réponse{{HTTPStatus("201")}} (Created).

+ +
HTTP/1.1 201 Created
+Content-Location: /new.html
+ +

Si la ressource ciblée a déjà une représentation et que cette représentation est modifiée avec succès, conformément à l'état de la représentation jointe, alors le serveur d'origine doit envoyer une réponse, que ce soit {{HTTPStatus("200")}} (OK) ou {{HTTPStatus("204")}} (No Content), pour indiquer la réussite de la requête.

+ +
HTTP/1.1 204 No Content
+Content-Location: /existing.html
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "PUT", "4.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/trace/index.html b/files/fr/web/http/methods/trace/index.html new file mode 100644 index 0000000000..cc58e561ca --- /dev/null +++ b/files/fr/web/http/methods/trace/index.html @@ -0,0 +1,77 @@ +--- +title: TRACE +slug: Web/HTTP/Méthode/TRACE +tags: + - HTTP + - Reference + - requête +translation_of: Web/HTTP/Methods/TRACE +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP TRACE effectue un test de rebouclage des messages le long du chemin vers la ressource cible, fournissant ainsi un mécanisme de débogage utile.

+ +

Le destinataire final de la demande doit renvoyer au client le message reçu, à l'exclusion de certains champs décrits ci-dessous, en tant que corps de message d'une réponse {{HTTPStatus("200")}}. (OK) avec un {{HTTPHeader("Content-Type")}} de message/http. Le destinataire final est soit le serveur d'origine, soit le premier serveur à recevoir une valeur {{HTTPHeader("Max-Forwards")}} de 0 dans la requête.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La demande a un corpsNon
Une réponse réussie a un corpsNon
{{Glossary("Safe")}}Non
{{Glossary("Idempotent")}}Oui
{{Glossary("Cacheable")}}Non
Autorisé dans les formulaires HTMLNon
+ +

Syntaxe

+ +
TRACE /index.html
+
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.methods.TRACE")}}

+ +

Voir également

+ + diff --git "a/files/fr/web/http/m\303\251thode/connect/index.html" "b/files/fr/web/http/m\303\251thode/connect/index.html" deleted file mode 100644 index 62b1ee7d6c..0000000000 --- "a/files/fr/web/http/m\303\251thode/connect/index.html" +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: CONNECT -slug: Web/HTTP/Méthode/CONNECT -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/CONNECT ---- -
{{HTTPSidebar}}
- -

La méthode HTTP CONNECT crée une communication bidirectionnelle avec la ressource demandée. Elle peut être utilisée pour ouvrir un tunnel.

- -

Par exemple, la méthode CONNECT peut être utilisée pour accéder à des sites web qui utilisent {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). Le client demande à un serveur Proxy HTTP de créer un tunnel TCP vers la destination désirée. Le serveur poursuit alors afin d'établir la connexion pour le compte du client. Une fois que la connexion a été établie par le serveur, le serveur Proxy continue de gérer le flux TCP à destination et en provenance du client.

- -

CONNECT est une méthode "saut-par-saut".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsOui
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Non
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
CONNECT www.example.com:443 HTTP/1.1
-
- -

Exemple

- -

Certains serveurs proxy pourraient avoir besoin d'une autorisation pour créer un tunnel. Voir aussi l'en-tête {{HTTPHeader("Proxy-Authorization")}}.

- -
CONNECT server.example.com:80 HTTP/1.1
-Host: server.example.com:80
-Proxy-Authorization: basic aGVsbG86d29ybGQ=
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- - - -

{{Compat("http/methods", "CONNECT")}}

- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/delete/index.html" "b/files/fr/web/http/m\303\251thode/delete/index.html" deleted file mode 100644 index d2a40a8ea9..0000000000 --- "a/files/fr/web/http/m\303\251thode/delete/index.html" +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: DELETE -slug: Web/HTTP/Méthode/DELETE -tags: - - HTTP - - HTTP method - - Reference - - Request method -translation_of: Web/HTTP/Methods/DELETE ---- -
{{HTTPSidebar}}
- -

La méthode HTTP DELETE supprime la ressource indiquée.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
DELETE /file.html HTTP/1.1
-
- -

Exemple

- -

Requête

- -
DELETE /file.html HTTP/1.1
- -

Réponses

- -

Si une méthode DELETE est appliquée avec succès, il y a plusieurs codes de statut de réponse possibles :

- - - -
HTTP/1.1 200 OK
-Date: Wed, 21 Oct 2015 07:28:00 GMT
-
-<html>
-  <body>
-    <h1>File deleted.</h1>
-  </body>
-</html>
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "DELETE", "4.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/get/index.html" "b/files/fr/web/http/m\303\251thode/get/index.html" deleted file mode 100644 index 008f479d98..0000000000 --- "a/files/fr/web/http/m\303\251thode/get/index.html" +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: GET -slug: Web/HTTP/Méthode/GET -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/GET ---- -
{{HTTPSidebar}}
- -

La méthode HTTP GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Safe","Sûre")}}Oui
{{Glossary("Idempotent","Idempotente")}}Oui
{{Glossary("Cacheable","Peut être mise en cache")}}Oui
Autorisée dans les formulaires HTMLOui
- -

Syntaxe

- -
GET /index.html
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- - - -

{{Compat("http/methods", "GET")}}

- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/head/index.html" "b/files/fr/web/http/m\303\251thode/head/index.html" deleted file mode 100644 index f89bbdde39..0000000000 --- "a/files/fr/web/http/m\303\251thode/head/index.html" +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: HEAD -slug: Web/HTTP/Méthode/HEAD -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/HEAD ---- -
{{HTTPSidebar}}
- -

La méthode HTTP HEAD demande les en-têtes qui seraient retournés si la ressource spécifiée était demandée avec une méthode HTTP {{HTTPMethod("GET")}}. Une telle requête peut être envoyée avant de procéder au téléchargement d'une  ressource volumineuse, par exemple pour économiser de la bande passante.

- -

Une réponse issue d'une requête HEAD ne doit pas avoir de corps. Si tel est le cas, elle doit être ignorée. Toutefois, les {{glossary("En-têtes d'entité", "en-têtes d'entité")}} décrivant le contenu du corps, comme {{HTTPHeader("Content-Length")}}, peuvent être inclus dans la réponse. Ils ne sont pas liés au corps de la réponse HEAD , qui doit être vide, mais au corps d'une réponse issue d'une requête similaire utilisant la méthode {{HTTPMethod("GET")}}.

- -

Si le résultat d'une requête HEAD montre qu'une ressource mise en cache après une requête {{HTTPMethod("GET")}} est désormais dépassée, le cache est invalidé, même si aucune requête GET n'a été émise.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Oui
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
HEAD /index.html
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "HEAD", "4.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- - - -

{{Compat("http/methods", "HEAD")}}

- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/index.html" "b/files/fr/web/http/m\303\251thode/index.html" deleted file mode 100644 index 25ae456c7c..0000000000 --- "a/files/fr/web/http/m\303\251thode/index.html" +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Méthodes de requête HTTP -slug: Web/HTTP/Méthode -tags: - - HTTP - - Méthodes - - Reference -translation_of: Web/HTTP/Methods ---- -
{{HTTPSidebar}}
- -

HTTP définit un ensemble de méthodes de requête qui indiquent l'action que l'on souhaite réaliser sur la ressource indiquée. Bien qu'on rencontre également des noms (en anglais), ces méthodes sont souvent appelées verbes HTTP. Chacun d'eux implémente une sémantique différente mais certaines fonctionnalités courantes peuvent être partagées par différentes méthodes (e.g. une méthode de requête peut être sûre (safe), idempotente ou être mise en cache (cacheable)).

- -
-
GET
-
La méthode GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.
-
HEAD
-
La méthode HEAD demande une réponse identique à une requête GET pour laquelle on aura omis le corps de la réponse (on a uniquement l'en-tête).
-
POST
-
La méthode POST est utilisée pour envoyer une entité vers la ressource indiquée. Cela  entraîne généralement un changement d'état ou des effets de bord sur le serveur.
-
PUT
-
-

La méthode PUT remplace toutes les représentations actuelles de la ressource visée par le contenu de la requête.

-
-
DELETE
-
La méthode DELETE supprime la ressource indiquée.
-
CONNECT
-
-

La méthode CONNECT établit un tunnel vers le serveur identifié par la ressource cible.

-
-
OPTIONS
-
La méthode OPTIONS est utilisée pour décrire les options de communications avec la ressource visée.
-
TRACE
-
-

La méthode TRACE réalise un message de test aller/retour en suivant le chemin de la ressource visée.

-
-
PATCH
-
La méthode PATCH est utilisée pour appliquer des modifications partielles à une ressource.
-
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationTitreCommentaires
{{RFC("7231", "Request methods", "4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentDéfinition de GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS et TRACE.
{{RFC("5789", "Patch method", "2")}}PATCH Method for HTTPDéfinition de PATCH.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http/methods")}}

- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/options/index.html" "b/files/fr/web/http/m\303\251thode/options/index.html" deleted file mode 100644 index ccdd97ef59..0000000000 --- "a/files/fr/web/http/m\303\251thode/options/index.html" +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: OPTIONS -slug: Web/HTTP/Méthode/OPTIONS -translation_of: Web/HTTP/Methods/OPTIONS ---- -
{{HTTPSidebar}}
- -

La méthode HTTP OPTIONS est utilisée pour décrire les options de communication pour la ressource ciblée. Le client peut renseigner une URL spécifique pour la méthode OPTIONS, ou une astérisque (*) pour interroger le serveur dans sa globalité.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

 

- -

Syntaxe

- -
OPTIONS /index.html HTTP/1.1
-OPTIONS * HTTP/1.1
-
- -

Examples

- -

Identifier les méthodes HTTP autorisées

- -

Pour déterminer les méthodes HTTP supportées par le serveur, on peut utiliser curl et envoyer une requête OPTIONS :

- -
curl -X OPTIONS http://example.org -i
- -

La réponse contient un en-tête {{HTTPHeader("Allow")}} qui liste les méthodes autorisées :

- -
HTTP/1.1 200 OK
-Allow: OPTIONS, GET, HEAD, POST
-Cache-Control: max-age=604800
-Date: Thu, 13 Oct 2016 11:45:00 GMT
-Expires: Thu, 20 Oct 2016 11:45:00 GMT
-Server: EOS (lax004/2813)
-x-ec-custom-error: 1
-Content-Length: 0
-
- -

Requête de pré-vérification cross-origin CORS

- -

En CORS, une requête de pré-vérification est envoyée avec la méthode OPTIONS afin que le serveur indique si la requête est acceptable avec les paramètres spécifiés. En tant qu'élément de la requête de pré-vérification, le header {{HTTPHeader("Access-Control-Request-Method")}} notifie le serveur que lorsque la véritable requête sera envoyée, ce sera avec une méthode POST. Le header {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que lorsque la vraie requête sera envoyée, elle aura les en-tête personnalisés X-PINGOTHER et Content-Type. Le serveur a maintenant la possibilité de déterminer s'il souhaite ou non accepter la requête dans les conditions énoncées par la requête de pré-vérification.

- -
OPTIONS /resources/post-here/ HTTP/1.1
-Host: bar.other
-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://foo.example
-Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
- -

Dans la réponse du serveur, l'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique que les méthodes POST, GET, and OPTIONS sont utilisables pour interroger la ressource.  Cet en-tête est similaire à {{HTTPHeader("Allow")}}, mais utilisé uniquement dans le contexte CORS.

- -
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://foo.example
-Access-Control-Allow-Methods: POST, GET, OPTIONS
-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
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "OPTIONS", "4.3.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.methods.OPTIONS")}}

- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/patch/index.html" "b/files/fr/web/http/m\303\251thode/patch/index.html" deleted file mode 100644 index aca3dfe6d4..0000000000 --- "a/files/fr/web/http/m\303\251thode/patch/index.html" +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: PATCH -slug: Web/HTTP/Méthode/PATCH -translation_of: Web/HTTP/Methods/PATCH ---- -

La méthode PATCH d'une requête HTTP applique des modifications partielles à une ressource.

- -

La méthode HTTP {{HTTPMethod("PUT")}} est déjà définie pour écraser une ressource avec un nouveau corps complet de message, et pour la méthode HTTP {{HTTPMethod("POST")}}, il n'existe aucun moyen standard pour découvrir le support de format de patch. Tout comme POST, la méthode HTTP PATCH n'est pas listée comme étant idempotent, contrairement à PUT. Cela signifie que les requêtes patch identiques et successives auront des effets différents sur l'objet manipulé.

- -

Pour découvrir si un serveur supporte la méthode PATCH, un serveur peut annoncer son support en l'ajoutant à la liste des méthodes autorisées dans les headers de la réponse {{HTTPHeader ("Allow")}} ou encore {{HTTPHeader ("Access-Control-Allow-Methods")}} (pour CORS).

- -

Une autre indication (implicite) que la méthode PATCH est autorisée est la présence du header {{HTTPHeader("Accept-Patch")}}.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête possède un corps de message (body)Oui
Une requête traitée avec succès retourne une réponse avec un corps de message (body)Non
{{Glossary("Safe")}}Non
{{Glossary("Idempotent")}}Non
{{Glossary("Cacheable")}}Non
Utilisation au sein des formulaires HTMLNon
- -

Syntaxe

- -
PATCH /file.txt HTTP/1.1
-
- -

Exemple

- -

Requête

- -
PATCH /file.txt HTTP/1.1
-Host: www.example.com
-Content-Type: application/example
-If-Match: "e0023aa4e"
-Content-Length: 100
-
-[description des changements]
- -

Réponse

- -

Une requête traitée avec succès retourne une réponse accompagnée d'un code de réponse {{HTTPStatus("204")}}. Dans ce cas-ci, la réponse ne contient un corps de message.

- -
HTTP/1.1 204 No Content
-Content-Location: /file.txt
-ETag: "e0023aa4f"
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("5789", "PATCH")}}Méthode PATCH pour HTTP (PATCH Method for HTTP)
- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/post/index.html" "b/files/fr/web/http/m\303\251thode/post/index.html" deleted file mode 100644 index e534246de7..0000000000 --- "a/files/fr/web/http/m\303\251thode/post/index.html" +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: POST -slug: Web/HTTP/Méthode/POST -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/POST ---- -
{{HTTPSidebar}}
- -

La méthode HTTP POST envoie des données au serveur. Le type du corps de la requête est indiqué par l'en-tête {{HTTPHeader("Content-Type")}}.

- -

La différence entre PUT et {{HTTPMethod("POST")}} tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

- -

Une requête POST est habituellement envoyée via un formulaire HTML et a pour résultat un changement sur le serveur. Dans ce cas, le type du contenu est sélectionné en mettant la chaîne de caractères adéquate dans l'attribut {{htmlattrxref("enctype", "form")}} de l'élément {{HTMLElement("form")}} ou dans l'attribut {{htmlattrxref("formenctype", "input")}} de l'élément {{HTMLElement("input") }}, voir celui des éléments {{HTMLElement("button")}} :

- - - -

Lorsque la requête POST est envoyée par un autre moyen qu'un formulaire HTML, par exemple via {{domxref("XMLHttpRequest")}}, le corps peut être de n'importe quel type. Comme décrit dans la spécification HTTP 1.1, la méthode POST est conçue pour permettre une méthode uniforme couvrant les fonctions suivantes :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsOui
Une réponse inclut un corpsOui
{{Glossary("Safe","Sûre")}}Non
{{Glossary("Idempotent","Idempotente")}}Non
{{Glossary("Cacheable","Peut être mise en cache")}}Seulement si une information de péremption est incluse
Autorisée dans les  formulaires HTMLOui
- -

Syntaxe

- -
POST /index.html
-
- -

Exemple

- -

Un formulaire simple utilisant le type de contenu par défaut application/x-www-form-urlencoded :

- -
POST / HTTP/1.1
-Host: foo.com
-Content-Type: application/x-www-form-urlencoded
-Content-Length: 13
-
-say=Hi&to=Mom
- -

Un formulaire utilisant le type de contenu multipart/form-data :

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

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.methods.POST")}}

- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/put/index.html" "b/files/fr/web/http/m\303\251thode/put/index.html" deleted file mode 100644 index d6e7dbeeb7..0000000000 --- "a/files/fr/web/http/m\303\251thode/put/index.html" +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: PUT -slug: Web/HTTP/Méthode/PUT -tags: - - HTTP - - HTTP method - - Reference - - Request method -translation_of: Web/HTTP/Methods/PUT ---- -
{{HTTPSidebar}}
- -

La méthode HTTP PUT crée une nouvelle ressource ou remplace une représentation de la ressource ciblée par le contenu de la requête.

- -

La différence entre PUT et POST tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsOui
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
PUT /new.html HTTP/1.1
-
- -

Exemple

- -

Requête

- -
PUT /new.html HTTP/1.1
-Host: example.com
-Content-type: text/html
-Content-length: 16
-
-<p>New File</p>
- -

Réponses

- -

Si la ressource ciblée ne possède pas de représentation courante et que la requête PUT en crée une avec succès, alors le serveur d'origine doit informer l'agent utilisateur en envoyant une réponse{{HTTPStatus("201")}} (Created).

- -
HTTP/1.1 201 Created
-Content-Location: /new.html
- -

Si la ressource ciblée a déjà une représentation et que cette représentation est modifiée avec succès, conformément à l'état de la représentation jointe, alors le serveur d'origine doit envoyer une réponse, que ce soit {{HTTPStatus("200")}} (OK) ou {{HTTPStatus("204")}} (No Content), pour indiquer la réussite de la requête.

- -
HTTP/1.1 204 No Content
-Content-Location: /existing.html
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "PUT", "4.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git "a/files/fr/web/http/m\303\251thode/trace/index.html" "b/files/fr/web/http/m\303\251thode/trace/index.html" deleted file mode 100644 index cc58e561ca..0000000000 --- "a/files/fr/web/http/m\303\251thode/trace/index.html" +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: TRACE -slug: Web/HTTP/Méthode/TRACE -tags: - - HTTP - - Reference - - requête -translation_of: Web/HTTP/Methods/TRACE ---- -
{{HTTPSidebar}}
- -

La méthode HTTP TRACE effectue un test de rebouclage des messages le long du chemin vers la ressource cible, fournissant ainsi un mécanisme de débogage utile.

- -

Le destinataire final de la demande doit renvoyer au client le message reçu, à l'exclusion de certains champs décrits ci-dessous, en tant que corps de message d'une réponse {{HTTPStatus("200")}}. (OK) avec un {{HTTPHeader("Content-Type")}} de message/http. Le destinataire final est soit le serveur d'origine, soit le premier serveur à recevoir une valeur {{HTTPHeader("Max-Forwards")}} de 0 dans la requête.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La demande a un corpsNon
Une réponse réussie a un corpsNon
{{Glossary("Safe")}}Non
{{Glossary("Idempotent")}}Oui
{{Glossary("Cacheable")}}Non
Autorisé dans les formulaires HTMLNon
- -

Syntaxe

- -
TRACE /index.html
-
- -

Specifications

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.methods.TRACE")}}

- -

Voir également

- - diff --git a/files/fr/web/http/overview/index.html b/files/fr/web/http/overview/index.html new file mode 100644 index 0000000000..33d2758ec2 --- /dev/null +++ b/files/fr/web/http/overview/index.html @@ -0,0 +1,178 @@ +--- +title: Un aperçu de HTTP +slug: Web/HTTP/Aperçu +tags: + - Aperçu + - HTML + - HTTP + - WebMechanics +translation_of: Web/HTTP/Overview +--- +
{{HTTPSidebar}}
+ +

HTTP est un {{glossary("protocole")}} qui permet de récupérer des ressources telles que des documents HTML. Il est à la base de tout échange de données sur le Web. C'est un protocole de type client-serveur, ce qui signifie que les requêtes sont initiées par le destinataire (qui est généralement un navigateur web). Un document complet est construit à partir de différents sous-documents qui sont récupérés, par exemple du texte, des descriptions de mise en page, des images, des vidéos, des scripts et bien plus.

+ +

Un document web se compose de différentes ressources

+ +

Les clients et serveurs communiquent par l'échange de messages individuels (en opposition à un flux de données). Les messages envoyés par le client, généralement un navigateur web, sont appelés des requêtes et les messages renvoyés par le serveur sont appelés réponses.

+ +

HTTP est un protocole de la couche d'application fonctionnant au-dessus de TCP (pour la couche de transport) et IP (pour la couche réseau). HTTP est en dessous de la couche de présentation. Conçu au début des années 1990, HTTP est un protocole extensible qui a évolué au cours du temps. C'est un protocole de la couche application dont les données transitent via {{glossary("TCP")}} ou à travers une connexion TCP chiffrée avec {{glossary("TLS")}}. En théorie, tout protocole de transport fiable pourrait être utilisé. En raison de son extensibilité, il n'est pas seulement utilisé pour récupérer des documents, mais aussi pour des images, des vidéos ou bien pour renvoyer des contenus vers des serveurs, comme des résultats de formulaires HTML. HTTP peut aussi être utilisé pour récupérer des parties de documents pour mettre à jour à la demande des pages web.

+ +

Composants des systèmes basés sur HTTP

+ +

HTTP est un protocole client-serveur : les requêtes sont envoyées par une entité : l'agent utilisateur (ou le proxy qui agit au nom de celui-ci). La majorité du temps, l'agent utilisateur est un navigateur web, mais cela peut-être n'importe quoi, un robot qui analyse le Web pour remplir et maintenir l'index d'un moteur de recherche est un exemple d'agent utilisateur.

+ +

Chaque requête individuelle est envoyée au serveur, qui la traite et fournit une réponse. Entre cette requête et la réponse se trouve de nombreuses entités qu'on désignera de façon générique sous le terme {{glossary("Proxy", "proxies")}}. Celles-ci exécutent différentes opérations et agissent comme passerelles ou comme {{glossary("Cache", "caches")}} par exemple.

+ +

chaîne client serveur

+ +

En réalité, il y a plus d'un ordinateur entre un navigateur et le serveur qui traite la requête : il y a les routeurs, les modems et bien plus. Grâce à la construction en couche du Web, ces intermédiaires sont cachés dans les couches réseau et transport. HTTP est bâti sur la couche applicative. Bien qu'elles puissent s'avérer importantes lorsqu'il s'agit de diagnostiquer des problèmes réseau, les couches inférieures ne sont pas pertinentes ici pour décrire HTTP.

+ +

Le client : l'agent  utilisateur

+ +

L'agent utilisateur correspond à n'importe quel outil qui agit pour le compte de l'utilisateur. Ce rôle est principalement rempli par le navigateur web ; les exceptions étant les programmes utilisés par des ingénieurs et développeurs web pour le débogage de leurs applications.

+ +

Le navigateur est toujours celui qui initie la requête. Il ne s'agit jamais du serveur (bien que certains mécanismes aient été ajoutés au cours des années afin de simuler les messages initiés par un serveur).

+ +

Pour afficher une page web, le navigateur envoie une requête initiale pour récupérer le document HTML depuis la page. Ensuite, il analyse le fichier et récupère les requêtes additionnelles qui correspondent aux scripts, aux informations de mise en page (CSS) et les sous-ressources contenues dans la page (généralement des images et des vidéos). Le navigateur web assemble alors ces ressources pour présenter un document complet à l'utilisateur : c'est la page web. Les scripts exécutés par le navigateur peuvent permettre de récupérer plus de ressources par la suite afin de mettre à jour la page web.

+ +

Une page web est un document hypertexte. Cela signifie que certaines parties sont des liens qui peuvent être activés (généralement avec un clic de souris) afin de récupérer une nouvelle page web, permettant à l'utilisateur de diriger son agent utilisateur et de naviguer sur le Web. Le navigateur traduit ces instructions en requêtes HTTP et interprète les réponses HTTP pour présenter une réponse claire à l'utilisateur.

+ +

Le serveur web

+ +

De l'autre côté du canal de communication, on trouve le serveur qui sert le document demandé par le client. Bien qu'on présente virtuellement le serveur comme un seul ordinateur, en réalité, il peut s'agir d'un ensemble de serveurs se répartissant la charge (load balancing) ou d'une architecture logicielle complexe qui interroge d'autres serveurs (par exemple un cache, un serveur de base de données, serveur d'e-commerce…), qui génèrent totalement ou partiellement le document à la demande.

+ +

D'une part, un serveur n'est pas nécessairement une machine unique et d'autre part, plusieurs serveurs peuvent être hébergés sur une même machine. Avec HTTP/1.1 et l'en-tête {{HTTPHeader("Host")}}, ils peuvent également partager la même adresse IP.

+ +

Les proxys

+ +

Entre le navigateur Web et le serveur, de nombreux ordinateurs et machines relaient les messages HTTP. En raison de la structure en couches superposées des technologies web, la plupart des opérations  au niveau du transport, du réseau ou au niveau physique sont transparents pour la couche HTTP, ce qui peut avoir un impact significatif sur les performances. Les opérations au niveau de la couche applicative sont généralement appelées proxy. Ceux-ci peuvent être transparents ou non (en changeant les requêtes qui passent par eux), et peuvent effectuer de nombreuses tâches :

+ + + +

Principaux aspects d'HTTP

+ +

HTTP est simple

+ +

Même s'il est devenu plus complexe avec l'arrivée d'HTTP/2 et l'encapsulation des messages HTTP dans des trames, HTTP est généralement conçu pour être simple et lisible par un humain. Les messages HTTP peuvent être lus et compris par des humains, ce qui facilite les tests des développeurs et réduit la complexité pour les débutants.

+ +

HTTP est extensible

+ +

À partir de HTTP/1.0, les en-têtes HTTP permettent d'étendre facilement le protocole et de mener des expérimentations avec celui-ci. De nouvelles fonctionnalités peuvent même être introduites par un simple accord entre le client et le serveur à propos de la sémantique des nouveaux en-têtes.

+ +

HTTP est sans état, mais pas sans session

+ +

HTTP est sans état : il n'y a pas de lien entre deux requêtes qui sont effectuées successivement sur la même connexion. Cela devient très rapidement problématique lorsque les utilisateurs veulent interagir avec une page de façon cohérente, par exemple avec un panier d'achat sur un site de commerce en ligne. Bien que le cœur d'HTTP soit sans état, les cookies HTTP permettent l'utilisation de sessions avec des états. En utilisant l'extensibilité par les en-têtes, des cookies HTTP sont ajoutés aux flux et permettent la création d'une session sur chaque requête HTTP pour partager un même contexte, ou un même état.

+ +

HTTP et les connexions

+ +

Une connexion est contrôlée au niveau de la couche transport et est donc fondamentalement hors de portée d'HTTP. Bien que HTTP ne nécessite pas un protocole de transport basé sur une connexion. Le protocole doit être fiable ou empêcher la perte de messages (donc gérer au minimum la remontée des erreurs). Parmi les deux protocoles de transport les plus courants sur Internet, TCP est fiable et UDP ne l'est pas. HTTP s'appuie sur le standard TCP, qui est basé sur la connexion, même si une connexion n'est pas toujours nécessaire.

+ +

HTTP/1.0 ouvre une connexion TCP pour chaque échange requête/réponse, ce qui introduit deux défauts majeur : l'ouverture d'une connexion nécessite plusieurs allers-retours, ce qui est lent mais devient plus efficace lorsque plusieurs messages sont envoyés et envoyés régulièrement. On dit aussi que les connexions qui restent chaudes sont plus efficaces que les communications froides.

+ +

Afin de réduire ces défauts, HTTP/1.1 introduit le pipelining (qui s'est avéré difficile à mettre en œuvre) et les connexions persistantes : la connexion TCP sous-jacente peut être partiellement contrôlée en utilisant l'en-tête {{HTTPHeader("Connection")}}. HTTP/2 va plus loin en multiplexant des messages sur une seule connexion, ce qui aide à maintenir la connexion chaude et plus efficace

+ +

Des expérimentations sont en cours afin de concevoir un protocole de transport plus adapté pour HTTP. Par exemple, Google expérimente QUIC, construit sur UDP pour fournir un protocole de transport plus fiable et efficace.

+ +

Ce qui peut être contrôlé par HTTP

+ +

Au fil du temps, la nature extensible de HTTP a permis de mieux contrôler le Web et d'y ajouter de nouvelles fonctionnalités. Les méthodes de cache ou d'authentification sont des fonctions qui furent gérées dès le début de HTTP tandis que la possibilité de lever la contrainte d'unicité de l'origine ne fut introduite qu'à partir des années 2010.

+ +

Voici une liste de fonctionnalités courantes, qui peuvent être contrôlées grâce à HTTP.

+ + + +

Flux HTTP

+ +

Lorsqu'un client veut communiquer avec un serveur, que ce soit avec un serveur final ou un proxy intermédiaire, il réalise les étapes suivantes :

+ +
    +
  1. Il ouvre une connexion TCP : la connexion TCP va être utilisée pour envoyer une ou plusieurs requêtes et pour recevoir une réponse. Le client peut ouvrir une nouvelle connexion, réutiliser une connexion existante ou ouvrir plusieurs connexions TCP vers le serveur.
    2. +
  2. Il envoie un message HTTP : les messages HTTP (avant HTTP/2) sont lisibles par les humains. Avec HTTP/2, ces simples messages sont en-capsulés dans des trames, rendant la lecture directe impossible, mais le principe reste le même. + 
    GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
    +
    3. +
  3. Il lit la réponse envoyée par le serveur : + 
    HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (suivi des 29769 octets de la page web demandée)
    +
    4. +
  4. Il ferme ou réutilise la connexion pour les requêtes suivantes.
    5. +
+ +

Si le pipeline HTTP est activé, plusieurs demandes peuvent être envoyées sans attendre que la première réponse soit entièrement reçue. Le pipeline HTTP s'est révélé difficile à implémenter dans les réseaux existants où de vieux logiciels coexistent avec des versions modernes. Le pipeline HTTP a été remplacé dans HTTP/2 par des requêtes de multiplexage plus robustes dans les trames.

+ +

Les messages HTTP

+ +

Les messages HTTP/1.1 et ceux des versions précédentes d'HTTP sont lisibles par des humains. Avec HTTP/2, ces messages sont intégrés dans une nouvelle structure binaire, une trame, ce qui permet des optimisations telles que la compression des en-têtes et le multiplexage. Même si seule une partie du message HTTP d'origine est envoyée dans cette version d'HTTP, la sémantique de chaque message est inchangée et le client reconstitue (virtuellement) la requête HTTP/1.1 d'origine. Il est donc utile de comprendre les messages HTTP/2 au format HTTP/1.1.

+ +

Il existe deux types de messages HTTP, les requêtes et les réponses, chacun ayant son propre format.

+ +

Requêtes

+ +

Un exemple de requête HTTP :

+ +

Une requête HTTP basique

+ +

Une requête comprend les éléments suivants :

+ + + +

Réponses

+ +

Un exemple de réponse :

+ +

une réponse HTTP

+ +

Une réponse comprend les éléments suivants:

+ + + +

Les APIs basées sur HTTP

+ +

L'API la plus utilisée se basant sur HTTP est l'API {{domxref("XMLHttpRequest")}} qui permet d'échanger des données entre un agent utilisateur {{Glossary("user agent")}} et un serveur.

+ +

Une autre API, server-sent events, est un service unidirectionnel permettant à un serveur d'envoyer des notifications au client, en se basant sur le protocole HTTP. À l'aide de l'utilisation de l'interface {{domxref("EventSource")}}, le client ouvre une connexion et initie un gestionnaire d'évènements. Le navigateur convertit alors automatiquement les messages du flux HTTP en objets de type {{domxref("Event")}}, pour ensuite les déléguer au gestionnaire d'évènements qui se sont abonnés à ce {{domxref("Event.type", "type")}} d'évènement. Dans le cas où le type est inconnu ou si aucun gestionnaire typé n'a été défini, ils sont délivrés au gestionnaire d'évènements {{domxref("EventSource.onmessage", "onmessage")}}.

+ +

Conclusion

+ +

HTTP est un protocole extensible, facile d'utilisation. La structure client-serveur, combinée avec la possibilité d'ajouter simplement des en-têtes, permet à HTTP de progresser au fur et mesure de l'ajout de nouvelles fonctionnalités sur le Web.

+ +

Bien que HTTP/2 ajoute de la complexité, en englobant les messages HTTP dans des trames pour améliorer les performances, la structure de base des messages est restée la même depuis HTTP/1.0. Le flux de session reste simple, ce qui lui permet d'être étudié et débogué avec un simple moniteur de message HTTP.

diff --git a/files/fr/web/http/public_key_pinning/index.html b/files/fr/web/http/public_key_pinning/index.html new file mode 100644 index 0000000000..287455b2e0 --- /dev/null +++ b/files/fr/web/http/public_key_pinning/index.html @@ -0,0 +1,170 @@ +--- +title: Public Key Pinning +slug: Web/Security/Public_Key_Pinning +tags: + - HTTPS + - Référence(2) + - Sécurité +translation_of: Web/HTTP/Public_Key_Pinning +--- +

L'extention Public Key Pinning pour HTTP (HPKP) est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques MITM avec des certificats contrefaits.

+ +
+

Note : La Public Key Pinning décrite ici est différente du limité preload list based key pinning introduit dans Firefox 32.

+
+ +

Pour s'assurer de l’authenticité de la clé publique du serveur utilisé dans une session TLS, cette clé publique est enveloppée dans un certificat X.509 qui est généralement signé par une autorité de certifications (CA, pour Certificate Authority). Les clients web tels que les navigateurs font confiance à beaucoup de ces autorités de certifications, et chacune d'entre elles peut créer des certificats pour des domaines arbitraires. Si un attaquant est capable de compromettre une seule de ces CA, il peut pratiquer des attaques {{Glossary("MitM")}} sur diverses connections TLS. HPKP peut contourner cette menace pour le protocole HTTPS en disant au client web quelles clés publiques appartiennent à un certain serveur web.

+ +

HPKP est une technique qui s'appuie sur la confiance au premier accès (TOFU, Trust on First Use). La première fois un serveur web dit au client en utilisant l'en-tête HTTP HPKP quelles clés publiques lui appartiennent, le client sauvegarde cette information pour une période de temps donnée. Quand le client visite le serveur à nouveau, il s'attend à un certificat contenant une clé publique dont l'empreinte est sauvegardée. Si le serveur présente une clé publique inconnue, le client doit présenter un avertissement à l'utilisateur.

+ +

Firefox (and Chrome) désactivent la vérification de l'épinglage lorsqu'un site épinglé présentent une chaine de certificats qui se termine par un certificat racine installé par l'utilisateur (et non un certificat racine de base).

+ +

Activer HPKP

+ +

Activer cette fonctionnalité pour votre site est simple : il faut juste retourner l'en tête HTTP Public-Key-Pins HTTP quand le site est accédé via HTTPS :

+ +
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"]
+
+ +
+
pin-sha256
+
La chaîne de caractère entre guillemets est l’empreinte du Subject Public Key Information (SPKI) encodé en base 64. Il est possible de spécifier plusieurs épinglage (pin) pour différentes clé publiques. Certains navigateurs pourraient autoriser dans le future d'autres algorithmes de hachage que SHA-256. Voir plus bas comment extraire cette information depuis le fichier d'un certificat ou d'une clé.
+
max-age
+
Le temps, en seconde, pendant laquelle le navigateur doit mémoriser que le site ne doit être visité qu'avec l'une des clés épinglées.
+
includeSubdomains {{ optional_inline() }}
+
Si ce paramètre optionnel est spécifié, cette règle s'applique aussi a tous les sous-domaines du domaine actuel.
+
report-uri {{ optional_inline() }}
+
Si ce paramètre optionnel est spécifié, les échecs de validation sont notifiés à l'URL donnée.
+
+ +
+

Note : La spécification actuelle impose d'inclure au minimum une seconde clé dite de sauvegarde, qui n'est pas encore utilisée en production. Cela permet de changer de clé publique sans bloquer l'accès aux clients qui auraient déjà noté les clés épinglés. C'est important par exemple dans le cas où la clé actuellement utilisées serait compromise, ce qui forcerait l'utilisation d'une clé différente (la clé de sauvegarde dans ce cas).

+
+ +
+

Note : Firefox n'implémente pas encore les rapports de violation d'épinglage. Chrome les implémente à partie de la version 46.

+ + +
+ +

 

+ +

Extraire la clé publique encodé en Base64

+ +

En premier, vous devez extraire la clé publique depuis votre fichier de certificats ou de clés puis l'encoder en base 64.

+ +

Les commandes suivantes vous aideront à extraire la clé publique et à l'encoder en base 64 depuis le fichier d'une clé, d'un certificat ou d'un CSR (Certificate Signing Request).

+ +
openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl x509 -in my-certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +

 

+ +

Exemple d'entête HPKP

+ +
Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubdomains; report-uri="https://www.example.net/hpkp-report"
+ +

Dans cet exemple, pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=" épingle la clé publique utilisée en production par le serveur. La deuxième déclaration d'épinglage pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=" représente la clé de sauvegarde. max-age=5184000 dit au client de mémoriser cette information pendant deux mois, ce qui est un temps raisonnable d'après la RFC. Cet épinglage s'applique aussi à tous les sous-domaines, car includeSubdomains est présent. Enfin, report-uri="https://www.example.net/hpkp-report" indique où envoyer les rapports d'erreurs de validation.

+ +

 

+ +

Mettre en place le header HPKP sur votre serveur web

+ +

Les étapes concrètes nécessaires pour délivrer l'en-tête HPKP dépendent du serveur web que vous utilisez.

+ +
+

Note: Ces exemples utilisent un a max-age de deux mois et incluent aussi tous les sous-domaines. Il est conseillé de vérifier que cela convient à votre serveur.

+
+ +

Inclure une ligne similaire à votre configuration activera HPKP, en remplaçant les valeurs en pointillé des lignes pin-sha256="..." :

+ +

Apache

+ +
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
+
+ +

Note : Cela demande le module mod_headers activé.

+ +

Nginx

+ +
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';
+ +

Note : Cela demande le module ngx_http_headers_module.

+ +

Lighttpd

+ +
setenv.add-response-header  = ( "Public-Key-Pins" => "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")
+ +

Note: Cela demande le module mod_setenv chargé, ce qui peut être fait en ajoutant la ligne suivante (s'il n'est pas déjà chargé) :

+ +
server.modules += ( "mod_setenv" )
+ +

 

+ +

Compatibilité des navigateurs

+ +

{{ CompatibilityTable() }}

+ +
+ + + + + + + + + + + + + + + + + + + +
FonctionnalitéChromeFirefox (Gecko)Internet ExplorerOperaSafari
Basic support{{ CompatChrome("38") }}{{ CompatGeckoDesktop("35") }}{{ CompatNo()}}{{ CompatUnknown() }}{{ CompatUnknown() }}
+
+ +
+ + + + + + + + + + + + + + + + + + + +
FonctionnalitéChrome pour AndroidFirefox Mobile (Gecko)IE MobileOpera MobileSafari Mobile
Basic support{{ CompatUnknown() }}{{ CompatGeckoMobile("35") }}{{CompatUnknown()}}{{ CompatUnknown() }}{{ CompatUnknown() }}
+
+ +

Spécifications

+ + + +

Voir également

+ + diff --git "a/files/fr/web/http/requ\303\252tes_conditionnelles/index.html" "b/files/fr/web/http/requ\303\252tes_conditionnelles/index.html" deleted file mode 100644 index 922b07a2fd..0000000000 --- "a/files/fr/web/http/requ\303\252tes_conditionnelles/index.html" +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: 'HTTP : Requêtes conditionnelles' -slug: Web/HTTP/Requêtes_conditionnelles -tags: - - Guide - - HTTP - - Requêtes Conditionnelles -translation_of: Web/HTTP/Conditional_requests ---- -

{{HTTPSidebar}}

- -

HTTP a 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 mettre de côté un contrôle inutile pour vérifier l'intégrité d'un document, comme le sommaire d'un téléchargement, ou éviter de perdre des mises à jour quand on télécharge ou modifie un document sur le serveur.

- -

Principes

- -

Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique des 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 :

- - - -

Validateurs

- -

Toutes les en-têtes conditionnelles 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 car comparer l'ensemble bit à bit n'est pas faisable et pas toujours désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il y en a de deux sortes :

- - - -

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

- - - -

La sorte de la vérification est indépendante du validateur utilisé.  {{HTTPHeader("Last-Modified")}} et {{HTTPHeader("ETag")}}  permettent les deux tupes 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

- -

La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, au bit prés. C'est obligatoire pour certaines en-têtes et le défaut pour les 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 perdu, parfois au détriment de la performance.

- -

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

- -

Validation faible

- -

La validation faible différe de la validation forte car elle considère que deux versions du document ayant le même contenu sont équivalentes. 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 seront évaluées comme étant 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 conditionnelles

- -

Plusieurs en-têtes HTTP, appelées en-têtes conditionelles, apportent des conditions aux reques. Ce sont :

- -
-
{{HTTPHeader("If-Match")}}
-
Succés si la {{HTTPHeader("ETag")}} de la ressource distante est égale à une de celles listées dans cette en-tête. Par défaut, à moins que l'etag soit préfixée 'W/', c'est une validation forte. it performs a strong validation.
-
{{HTTPHeader("If-None-Match")}}
-
Succés si la {{HTTPHeader("ETag")}} de la ressource distante est différente de toutes celles listées dans l'en-tête. Par défaut, à moins que l'etag soit préfixée 'W/', c'est une validation forte.
-
{{HTTPHeader("If-Modified-Since")}}
-
Succés si la date {{HTTPHeader("Last-Modified")}} de la ressource distante est plus récente que celle donnée dans l'en-tête.
-
-
{{HTTPHeader("If-Unmodified-Since")}}
-
Succés si la date {{HTTPHeader("Last-Modified")}} de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.
-
{{HTTPHeader("If-Range")}}
-
Similaire à {{HTTPHeader("If-Match")}}, ou {{HTTPHeader("If-Unmodified-Since")}}, mais peut n'avoir qu'une seule etag, ou une date. Si ça ne colle pas, la requête est rejetée et à la place d'un statut de réponse {{HTTPStatus("206")}} Partial Content , un {{HTTPStatus("200")}} OK est envoyé avec la totlité de la ressource.
-
- -

Cas d'utilisation

- -

Mise à jour du Cache

- -

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

- -

The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled.

- -

Dans la ressource les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs {{HTTPHeader("Last-Modified")}} et  {{HTTPHeader("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'esst publiée. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête {{HTTPHeader("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 {{HTTPHeader("If-Modified-Since")}} et {{HTTPHeader("If-Match")}}.

- -

Si la ressource n'a pas changé, le serveur renvoie une réponse {{HTTPStatus("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.

- -

With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same.

- -

Si la ressource n'a pas changée, le serveur renvoie juste une réponse  {{HTTPStatus("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.

- -

In the case where the resource was changed, it is sent back as if the request wasn't conditional.

- -

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

- -

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 :

- -

A download has been stopped and only partial content has been retrieved.

- -

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

- -

The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request.

- -

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 se sert de {{HTTPHeader("If-Modified-Since")}} et de  {{HTTPHeader("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 :

- -

When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely.

- -

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

- -

The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download.

- -

Cette solution est plus efficace mais légèrement moins flexible puisqu' une etag seulement peut être utilisée 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"

- -

Une opération commune des applications web est la mise à jour de document distants. C'est trés usuel dans tout système de fichiers ou dans les applications de contrôle de source et 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 {{HTTPMethod("PUT")}}. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.

- -

Updating a file with a PUT is very simple when concurrency is not involved.

- -

Cependant, les choses deviennent un peu moins précises dés que l'on parle de simultanéité des comptes. 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 "course des conditions" ({{glossary("race condition")}}) qui conduit à des comportements problématiques difficiles à cerner et à débugger.

- -

When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!

- -

Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre client. De toutes façons, les mises à jour perdues et la "course des conditions" sont appelées à disparaître. Nous voulons des résultats prévisibles et être notifiés quand les changements sont rejetés.

- -

Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (optimistic 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 :

- -

Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error.

- -

Ce ci est implémenté par les en-têtes {{HTTPHeader("If-Match")}} ou {{HTTPHeader("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 {{HTTPStatus("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

- -

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 "course des conditions" si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnelles peuvent être employées : on ajoute {{HTTPHeader("If-None-Match")}} avec la valeur particulière '*', représentant n'importe quelle etag. La requête aboutira seulement si la ressource n'existait pas avant :

- -

Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it.

- -

If-None-Match fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieur). Si vous n'êtes pas sûr que le serveur le soit, vous devez d'abord envoyer une requête {{HTTPMethod("HEAD")}} à la ressource pour vérifier.

- -

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 obligation du webmaster est de configurer le serveur correctement, en paramètrant les bonnes etags : dans certains environnements, c'est un véritable défi. Une fois cela fait, le serveur renverra les requêtes conditionnelles adaptées.

- -

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

- -

Dans les deux cas, c'est clair, les requêtes conditionnelles sont une des fonctionnalités essentielles du Web.

-- cgit v1.2.3-54-g00ecf