Worldlex Wiki 
de couche application de la suite de protocoles Internet pour les systèmes d'information hypermédia distribués et collaboratifs . HTTP est la base de la communication de données pour le World Wide Web , où les documents hypertextes incluent des hyperliens vers d'autres ressources auxquelles l'utilisateur peut facilement accéder, par exemple en cliquant sur la souris ou en touchant l'écran dans un navigateur Web .
HTTP est un protocole de type requête-réponse appartenant au modèle client-serveur . Une transaction débute par l'envoi d'une requête du client au serveur. Le serveur tente de satisfaire cette requête et renvoie une réponse au client décrivant le traitement de la requête et contenant éventuellement la ressource demandée, telle qu'un document HTML ou tout autre contenu.
Dans la plupart des cas, un navigateur web fait office de client , tandis qu'un serveur web , hébergeant un ou plusieurs sites web , joue le rôle de serveur . Un navigateur web est un exemple d' agent utilisateur (AU). Parmi les autres types d'agents utilisateurs, on trouve les logiciels d'indexation utilisés par les moteurs de recherche ( robots d'exploration web ), les navigateurs vocaux , les applications mobiles et autres logiciels qui accèdent au contenu web, le consomment ou l'affichent.
Le protocole HTTP est conçu pour permettre aux éléments intermédiaires du réseau d'améliorer ou de faciliter la communication entre clients et serveurs. Les sites web à fort trafic tirent souvent parti des serveurs de cache web qui diffusent le contenu pour le compte des serveurs en amont afin d'améliorer le temps de réponse. Les navigateurs web mettent en cache les ressources web précédemment consultées et les réutilisent, autant que possible, pour réduire le trafic réseau. Les serveurs proxy HTTP situés aux frontières d'un réseau privé peuvent faciliter la communication pour les clients ne disposant pas d'une adresse IP publique, en relayant les messages vers des serveurs externes.
Pour permettre aux nœuds HTTP intermédiaires (serveurs proxy, caches Web, etc.) d'accomplir leurs fonctions, certains en-têtes HTTP (présents dans les requêtes/réponses HTTP) sont gérés de bout en bout, tandis que d'autres en-têtes HTTP sont gérés de bout en bout (gérés uniquement par le client source et par le serveur Web cible).
Une ressource Web est localisée par un localisateur de ressources uniformes (URL), utilisant les schémas d'identificateurs de ressources uniformes (URI) http et https . Les URI sont encodées sous forme d'hyperliens dans les documents HTML , afin de former des documents hypertextes interconnectés .
de HTTP/2 et HTTP/3 .| Version | Introduit | Statut | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0,9 | 1991 | connexion TCP distincte est établie avec le même serveur pour chaque requête de ressource. En HTTP/1.1, une connexion TCP peut être réutilisée pour effectuer plusieurs requêtes de ressources (pages HTML, cadres, images, scripts , feuilles de style , etc.). Les communications HTTP/1.1 subissent donc une latence réduite , car l'établissement de connexions TCP engendre une surcharge considérable, notamment en cas de trafic important. Les améliorations apportées par HTTP/2 permettent de réduire la latence et, dans la plupart des cas, d'atteindre des débits supérieurs à ceux des communications HTTP/1.1. HTTP/2 prend notamment en charge :
HTTP/3 utilise les protocoles de transport QUIC et UDP au lieu de TCP. Seule la couche IP est utilisée (sur laquelle UDP, comme TCP, s'appuie). Cela améliore légèrement la vitesse moyenne des communications et évite les problèmes occasionnels de congestion des connexions TCP qui peuvent bloquer ou ralentir temporairement le flux de données de tous ses flux (une autre forme de « blocage en tête de file »). UtiliserLe protocole HTTP/2 est pris en charge par 71 % des sites web (34,1 % HTTP/2 + 36,9 % HTTP/3 avec rétrocompatibilité) et par la quasi-totalité des navigateurs web (plus de 98 % des utilisateurs) . Il est également pris en charge par les principaux serveurs web via le protocole TLS ( Transport Layer Security ) grâce à l' extension ALPN ( Application-Layer Protocol Negotiation ) , qui requiert TLS 1.2 ou une version ultérieure Le protocole HTTP/3 est utilisé sur 36,9 % des sites web et est pris en charge par la plupart des navigateurs web, soit (au moins partiellement) par 97 % des utilisateurs . HTTP/3 utilise QUIC au lieu de TCP comme protocole de transport sous-jacent. À l'instar de HTTP/2, il ne rend pas obsolètes les versions majeures précédentes du protocole. En 2019, la prise en charge de HTTP/3 a d'abord été ajoutée à Cloudflare et Chrome , puis activée dans Firefox . HTTP/3 offre une latence plus faible pour les pages web réelles et se charge plus rapidement que HTTP/2, parfois plus de trois fois plus vite que HTTP/1.1, qui reste souvent le seul protocole activé HTTPS , la variante sécurisée de HTTP, est utilisé par plus de 85 % des sites web. Technologiecouche de transportLe protocole HTTP présuppose un protocole de couche transport sous-jacent fiable . Avant HTTP/3, le protocole sous-jacent standard était le protocole TCP ( Transmission Control Protocol ). HTTP/3 utilise une couche transport différente, appelée QUIC , qui assure la fiabilité du protocole UDP (User Datagram Protocol ), non fiable. Les versions HTTP/1.1 et antérieures ont été adaptées pour être utilisées sur UDP non fiable, en situation de multidiffusion et d'unidiffusion , donnant naissance aux protocoles HTTPMU et HTTPU. Ces protocoles sont utilisés dans UPnP et SSDP ( Simple Service Discovery Protocol ), deux protocoles généralement exécutés sur un réseau local . échange de donnéesHTTP est un protocole applicatif sans état qui nécessite une connexion réseau fiable pour l'échange de données entre le client et le serveur. Dans les implémentations HTTP, des connexions TCP/IP sont utilisées avec des ports standard (généralement le port 80 pour une connexion non chiffrée et le port 443 pour une connexion chiffrée ; voir également la liste des numéros de ports TCP et UDP ). HTTP/2 utilise une connexion TCP/IP et plusieurs canaux de protocole. HTTP/3 utilise le protocole de transport applicatif QUIC sur UDP. Messages de requête et de réponse via les connexionsLes données sont échangées par une séquence de messages requête-réponse , transitant par une connexion de transport de la couche session . Un client HTTP tente initialement d'établir une connexion, réelle ou virtuelle, avec un serveur. Un serveur HTTP, à l'écoute sur le port spécifié, accepte la connexion et attend ensuite la requête du client. Le client envoie sa requête HTTP. À réception de celle-ci, le serveur renvoie une réponse HTTP, comprenant un ou plusieurs en-têtes et, le cas échéant, un corps. Le corps de cette réponse correspond généralement à la ressource demandée, mais un message d'erreur ou d'autres informations peuvent également être renvoyés. À tout moment et pour diverses raisons, le client ou le serveur peut fermer la connexion. La fermeture d'une connexion est généralement signalée par un ou plusieurs en-têtes HTTP dans la dernière requête ou réponse. Liens persistantsHTTP/1.1 a introduit le pipelining HTTP afin de réduire davantage le temps de latence lors de l'utilisation de connexions persistantes, en permettant aux clients d'envoyer plusieurs requêtes avant d'attendre chaque réponse. Cette optimisation n'a jamais été considérée comme totalement sûre, car certains serveurs web et de nombreux serveurs proxy , notamment les serveurs proxy transparents placés sur Internet/ Intranets entre les clients et les serveurs, ne géraient pas correctement les requêtes pipelinées (ils ne traitaient que la première requête en ignorant les suivantes, ils fermaient la connexion après avoir reçu davantage de données, ou certains proxys renvoyaient même les réponses dans le désordre, etc.). De ce fait, seules les requêtes HEAD et certaines requêtes GET (c'est-à-dire limitées aux requêtes de fichiers, donc avec des URL sans chaîne de requête utilisée comme commande, etc.) pouvaient être pipelinées de manière sûre et idempotente . Après de nombreuses années de difficultés liées aux problèmes engendrés par l'activation du pipelining, cette fonctionnalité a d'abord été désactivée, puis supprimée de la plupart des navigateurs. Le pipelining a également été abandonné suite à l'annonce de l'adoption de HTTP/2. HTTP/2 a étendu l'utilisation des connexions persistantes en multiplexant de nombreuses requêtes/réponses simultanées via une seule connexion TCP/IP. HTTP/3 n'utilise pas de connexions TCP/IP mais QUIC + UDP. Optimisations de la récupération de contenuEn HTTP/0.9, une ressource demandée était toujours envoyée dans son intégralité. HTTP/1.0 a ajouté des en-têtes pour gérer les ressources mises en cache par un client afin de permettre les requêtes GET conditionnelles.
HTTP/1.1 a été introduit et les versions ultérieures offrent :
session d'applicationprotocole sans état , HTTP ne requiert pas que le serveur web conserve des informations ou un statut concernant chaque utilisateur pendant plusieurs requêtes. Si une application web nécessite une session , elle l'implémente via des cookies HTTP , des variables cachées dans un formulaire web ou un autre mécanisme. | ||||||||||||||||||
| Méthode | RFC | La requête contient un corps de charge utile | La réponse contient un corps de charge utile | Sûr | Idempotent | Mise en cache | ||||||||||||||
| OBTENIR | RFC 9110 | RFC 9110 | RFC 9110 | RFC 9110 | RFC 9110 | RFC 9110 | RFC 9110 | RFC 9110 | RFC 5789 | en lecture seule . Elles peuvent néanmoins avoir des effets secondaires invisibles pour le client, comme l'ajout d'informations de requête à un fichier journal ou la facturation d'un compte publicitaire . En revanche, les méthodes POST, PUT, DELETE, CONNECT et PATCH ne sont pas sûres. Elles peuvent modifier l'état du serveur ou avoir d'autres effets, comme l'envoi d'un courriel . C'est pourquoi elles ne sont généralement pas utilisées par les robots d'exploration Web conformes ; certains robots non conformes ont tendance à effectuer des requêtes sans tenir compte du contexte ni des conséquences. Malgré la sécurité théorique des requêtes GET, leur traitement par le serveur n'est en pratique soumis à aucune limitation technique. Une programmation négligente ou délibérément irrégulière peut permettre aux requêtes GET d'entraîner des modifications importantes sur le serveur. Cette pratique est déconseillée en raison des problèmes pouvant survenir lorsque la mise en cache web , les moteurs de recherche et autres agents automatisés effectuent des modifications involontaires sur le serveur. Par exemple, un site web peut autoriser la suppression d'une ressource via une URL telle que https://example.com/article/1234/delete , qui, si elle est récupérée arbitrairement, même via GET, supprimerait simplement l'article. Un site web correctement codé exigerait une méthode DELETE ou POST pour cette action, ce que les robots non malveillants n'effectueraient pas. Un exemple concret de ce phénomène s'est produit lors de la brève période d'utilisation de la version bêta de Google Web Accelerator , qui préchargeait des URL arbitraires sur la page consultée par l'utilisateur, entraînant la modification ou la suppression automatique et massive d'enregistrements . La version bêta a été suspendue quelques semaines seulement après son lancement, suite à de nombreuses critiques. méthode idempotenteIl est important de noter que l'idempotence d'une méthode n'est pas garantie par le protocole ni par le serveur web. Il est tout à fait possible de concevoir une application web où, par exemple, une insertion dans une base de données ou toute autre action non idempotente est déclenchée par une requête GET ou autre. Toutefois, procéder ainsi, contrairement aux recommandations, peut avoir des conséquences indésirables si l'agent utilisateur suppose qu'il est sans risque de répéter la même requête alors que ce n'est pas le cas. Méthode pouvant être mise en cacheCode d'étathumain .ExempleL'exemple suivant illustre une transaction requête-réponse HTTP/1.1 pour un serveur situé à l'adresse www.example.com , port 80. HTTP/1.0 utiliserait les mêmes messages, à l'exception de quelques en-têtes manquants. HTTP/2 et HTTP/3 utiliseraient le même mécanisme requête-réponse, mais avec une représentation différente des en-têtes HTTP. Voici une requête sans corps. Elle se compose d'une ligne de début, de six champs d'en-tête et d'une ligne vide retour chariot et un saut de ligne . Le ETag (Entity Tag) est utilisé pour déterminer si une version mise en cache de la ressource demandée est identique à la version actuelle de la ressource sur le serveur. Ce Content-Typechamp d'en-tête spécifie le type de média Internet des données transmises par le message HTTP et Content-Lengthindique sa longueur en octets. Le serveur web HTTP/1.1 indique sa capacité à répondre aux requêtes portant sur une plage d'octets de la ressource en incluant `<bytes>` Accept-Ranges: bytes. Ceci est utile si le client a besoin que le serveur n'envoie que certaines portions d'une ressource ; on parle alors de service par octets . Lorsque `<bytes> Connection: close` est envoyé, cela signifie que le serveur web fermera la connexion TCP immédiatement après la fin du transfert de cette réponse. La plupart des champs d'en-tête sont facultatifs, mais certains sont obligatoires.
Accept-Ranges : bytes Connection : close<html> <head> <title> Une page d' exemple </title> </head> <body> <p> Bonjour le monde , ceci est un document HTML très simple . </p> </body> </html> Protocoles similaires
Histoire Tim Berners-Lee et son équipe du CERN sont reconnus comme les inventeurs du protocole HTTP, ainsi que du HTML et des technologies associées pour un serveur web et une interface utilisateur client appelée navigateur web . Berners-Lee a conçu HTTP afin de faciliter l'adoption de son autre idée : le projet « World Wide Web », proposé pour la première fois en 1989 et aujourd'hui connu sous le nom de World Wide Web . Le développement de HTTP a débuté en 1989 et a été résumé dans un document simple décrivant le comportement d'un client et d'un serveur utilisant la première version de HTTP, nommée 0.9. Cette version a ensuite été développée, pour finalement devenir la version publique 1.0. L'élaboration des premières RFC ( Request for Comments ) de HTTP a commencé quelques années plus tard, dans le cadre d'un effort coordonné entre l' IETF ( Internet Engineering Task Force ) et le W3C ( World Wide Web Consortium ), les travaux étant par la suite transférés à l'IETF. Le premier serveur web a été mis en service en 1990. Le protocole utilisé ne comportait qu'une seule méthode, GET, qui permettait de demander une page à un serveur. La réponse du serveur était toujours une page HTML. HTTP/0.9En 1991, la première version officielle documentée de HTTP a été écrite sous la forme d'un document simple, de moins de 700 mots, et cette version a été nommée HTTP/0.9, qui ne prenait en charge que la méthode GET, permettant aux clients de récupérer uniquement des documents HTML depuis le serveur, mais ne prenant en charge aucun autre format de fichier ni le téléchargement d'informations. HTTP/1.0-draftDepuis 1992, un nouveau document a été rédigé pour spécifier l'évolution du protocole de base vers sa version complète suivante. Il prenait en charge à la fois la méthode de requête simple de la version 0.9 et la requête GET complète incluant la version HTTP côté client. Il s'agissait du premier des nombreux brouillons non officiels de HTTP/1.0 qui ont précédé les travaux finaux sur HTTP/1.0. Groupe de travail HTTP du W3CAprès avoir décidé que de nouvelles fonctionnalités du protocole HTTP étaient nécessaires et qu'elles devaient être entièrement documentées dans des documents RFC officiels, le groupe de travail HTTP (HTTP WG, dirigé par Dave Raggett ) a été constitué début 1995 dans le but de normaliser et d'étendre le protocole avec des opérations étendues, une négociation étendue, des métadonnées plus riches, le tout lié à un protocole de sécurité qui devenait plus efficace grâce à l'ajout de méthodes et de champs d'en-tête supplémentaires . Le groupe de travail HTTP prévoyait de réviser et de publier de nouvelles versions du protocole sous les noms HTTP/1.0 et HTTP/1.1 au cours de l'année 1995, mais, en raison des nombreuses révisions, ce délai a duré bien plus d'un an. Le groupe de travail HTTP prévoyait également de spécifier une version beaucoup plus future de HTTP appelée HTTP-NG (HTTP Next Generation) qui aurait résolu tous les problèmes restants des versions précédentes, liés aux performances, aux réponses à faible latence, etc., mais ce travail n'a commencé que quelques années plus tard et n'a jamais été achevé. HTTP/1.0En mai 1996, la RFC 1945 a été publiée comme une révision finale HTTP/1.0 de ce qui avait été utilisé au cours des 4 années précédentes comme brouillon pré-standard HTTP/1.0 qui était déjà utilisé par de nombreux navigateurs Web et serveurs Web.l'hébergement virtuel , et qu'en juin 1996, 65 % des navigateurs accédant à ses serveurs étaient compatibles avec les versions préliminaires de HTTP/1.1. En janvier 1997, la RFC 2068 a été officiellement publiée en tant que spécifications HTTP/1.1.le multiplexage des transactions HTTP au sein d'une seule connexion TCP/IP, mais en 1999, le groupe a cessé ses activités, transférant les problèmes techniques à l'IETF. Le groupe de travail HTTP de l'IETF a redémarréEn 2007, le groupe de travail HTTP de l'IETF (HTTP WG bis ou HTTPbis) a été relancé, d'une part pour réviser et clarifier les spécifications HTTP/1.1 précédentes et d'autre part pour rédiger et affiner les futures spécifications HTTP/2 (nommées httpbis). SPDYHTTP/2Dépréciation de HTTP/0.9En 2014, le protocole HTTP/0.9 a été déprécié pour les serveurs prenant en charge la version HTTP/1.1 (et supérieure) :
Depuis 2016, de nombreux chefs de produit et développeurs d'agents utilisateurs (navigateurs, etc.) et de serveurs Web ont commencé à planifier la dépréciation et l'abandon progressifs du support du protocole HTTP/0.9, principalement pour les raisons suivantes :
En 2022, la prise en charge du protocole HTTP/0.9 n'était pas encore officiellement et totalement abandonnée ; elle restait présente dans de nombreux serveurs web et navigateurs (uniquement pour les réponses du serveur), même si elle était généralement désactivée. On ignore combien de temps il faudra pour que HTTP/0.9 soit complètement supprimé. HTTP/3Plus d articles de Worldlex WikiRevenez a l index pour explorer davantage de pages sur l histoire, la science, la culture, la geographie et la societe en francais. Explorer l index |