HTTP

HTTP ( Hypertext Transfer Protocol ) est un protocole de couche application dans le modèle de 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 par un clic de souris ou en appuyant sur l'écran dans un navigateur Web .

Le développement de HTTP a été initié par Tim Berners-Lee au CERN en 1989 et résumé dans un document simple décrivant le comportement d'un client et d'un serveur utilisant la première version HTTP, nommée 0.9. Cette version a ensuite été développée, devenant finalement la version publique 1.0.

Le développement des premières demandes de commentaires HTTP (RFC) a commencé quelques années plus tard dans le cadre d'un effort coordonné de l' Internet Engineering Task Force (IETF) et du World Wide Web Consortium (W3C), les travaux étant ensuite transférés à l'IETF.

HTTP/1 a été finalisé et entièrement documenté (en tant que version 1.0) en 1996. Il a évolué (en tant que version 1.1) en 1997, puis ses spécifications ont été mises à jour en 1999, 2014 et 2022. Sa variante sécurisée nommée HTTPS est utilisée par plus de 85 % des sites Web.

HTTP/2 , publié en 2015, fournit une expression plus efficace de la sémantique de HTTP « sur le fil ». En août 2024, il est pris en charge par 66,2 % des sites Web (35,3 % HTTP/2 + 30,9 % HTTP/3 avec rétrocompatibilité) et pris en charge par presque tous les navigateurs Web (plus de 98 % des utilisateurs). Il est également pris en charge par les principaux serveurs Web via Transport Layer Security (TLS) à l'aide d'une extension de négociation de protocole de couche application (ALPN) où TLS 1.2 ou une version plus récente est requise.

HTTP/3 , le successeur de HTTP/2, a été publié en 2022. En février 2024, il est désormais utilisé sur 30,9 % des sites Web et est pris en charge par la plupart des navigateurs Web, c'est-à-dire (au moins partiellement) pris en charge par 97 % des utilisateurs. HTTP/3 utilise QUIC au lieu de TCP pour le protocole de transport sous-jacent. Comme HTTP/2, il ne rend pas obsolètes les versions majeures précédentes du protocole. La prise en charge de HTTP/3 a d'abord été ajoutée à Cloudflare et Google Chrome , et est également activée dans Firefox . HTTP/3 a une latence plus faible pour les pages Web du monde réel, s'il est activé sur le serveur, et se charge plus rapidement qu'avec HTTP/2, dans certains cas plus de trois fois plus rapidement que HTTP/1.1 (qui est encore généralement uniquement activé).

HTTP fonctionne comme un protocole de requête-réponse dans le modèle client-serveur . Un navigateur Web , par exemple, peut être le client tandis qu'un processus , appelé serveur Web , exécuté sur un ordinateur hébergeant un ou plusieurs sites Web peut être le serveur . Le client soumet un message de requête HTTP au serveur. Le serveur, qui fournit des ressources telles que des fichiers HTML et d'autres contenus ou exécute d'autres fonctions pour le compte du client, renvoie un message de réponse au client. La réponse contient des informations sur l'état d'achèvement de la requête et peut également contenir le contenu demandé dans son corps de message.

Un navigateur Web est un exemple d' agent utilisateur (UA). D'autres types d'agents utilisateurs incluent les logiciels d'indexation utilisés par les fournisseurs de recherche ( robots Web ), les navigateurs vocaux , les applications mobiles et d'autres logiciels qui accèdent, consomment ou affichent du contenu Web.

Le protocole HTTP est conçu pour permettre aux éléments intermédiaires du réseau d'améliorer ou d'activer les communications entre les clients et les serveurs. Les sites Web à fort trafic bénéficient souvent de serveurs de cache Web qui fournissent du contenu au nom 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, chaque fois que cela est possible, pour réduire le trafic réseau. Les serveurs proxy HTTP aux limites du réseau privé peuvent faciliter la communication pour les clients sans adresse routable à l'échelle mondiale, en relayant les messages avec des serveurs externes.

Pour permettre aux nœuds HTTP intermédiaires (serveurs proxy, caches Web, etc.) d'accomplir leurs fonctions, certains des en-têtes HTTP (présents dans les requêtes/réponses HTTP) sont gérés saut par saut 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).

HTTP est un protocole de couche d'application conçu dans le cadre de la suite de protocoles Internet . Sa définition suppose un protocole de couche de transport sous-jacent et fiable . Dans HTTP/3 , le protocole de contrôle de transmission (TCP) n'est plus utilisé, mais les anciennes versions sont toujours plus utilisées et utilisent le plus souvent TCP. Elles ont également été adaptées pour utiliser des protocoles peu fiables tels que le protocole UDP (User Datagram Protocol ), sur lequel HTTP/3 s'appuie également (indirectement) toujours, par exemple dans HTTPU et Simple Service Discovery Protocol (SSDP).

Les ressources HTTP sont identifiées et localisées sur le réseau par des localisateurs de ressources uniformes (URL), à l'aide des schémas d'identifiants de ressources uniformes (URI) http et https . Comme défini dans la RFC 3986, les URI sont codés sous forme d'hyperliens dans les documents HTML , de manière à former des documents hypertextes interconnectés .

Dans HTTP/1.0, une connexion TCP distincte au même serveur est établie pour chaque demande de ressource.

Dans HTTP/1.1, une connexion TCP peut être réutilisée pour effectuer plusieurs demandes de ressources (c'est-à-dire des pages HTML, des cadres, des images, des scripts , des feuilles de style , etc.).

Les communications HTTP/1.1 connaissent donc moins de latence car l'établissement de connexions TCP présente une surcharge considérable, en particulier dans des conditions de trafic élevé.

HTTP/2 est une révision de la version précédente HTTP/1.1 afin de conserver le même modèle client-serveur et les mêmes méthodes de protocole, mais avec ces différences dans l'ordre :

• d’utiliser une représentation binaire compressée des métadonnées (en-têtes HTTP) au lieu d’une représentation textuelle, de sorte que les en-têtes nécessitent beaucoup moins d’espace ;
• d'utiliser une seule connexion TCP/IP (généralement cryptée ) par domaine de serveur consulté au lieu de 2 à 8 connexions TCP/IP ;
• utiliser un ou plusieurs flux bidirectionnels par connexion TCP/IP dans lesquels les requêtes et réponses HTTP sont décomposées et transmises en petits paquets pour résoudre presque le problème du HOLB ( head-of-line blocking ).
• d'ajouter une capacité push pour permettre à l'application serveur d'envoyer des données aux clients chaque fois que de nouvelles données sont disponibles (sans forcer les clients à demander périodiquement de nouvelles données au serveur en utilisant des méthodes d'interrogation ).

Les communications HTTP/2 connaissent donc une latence beaucoup plus faible et, dans la plupart des cas, des vitesses encore plus élevées que les communications HTTP/1.1.

HTTP/3 est une révision de la précédente version HTTP/2 afin d'utiliser les protocoles de transport QUIC + UDP au lieu de TCP. Avant cette version, les connexions TCP/IP étaient utilisées ; mais maintenant, 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 permet d'éviter le problème occasionnel (très rare) de congestion de la connexion TCP qui peut bloquer ou ralentir temporairement le flux de données de tous ses flux (une autre forme de « blocage en tête de file »).

Le terme hypertexte a été inventé par Ted Nelson en 1965 dans le cadre du projet Xanadu , lui-même inspiré par la vision de Vannevar Bush des années 1930 du système de recherche et de gestion d'informations sur microfilms « memex » décrit dans son essai de 1945 « As We May Think ». Tim Berners-Lee et son équipe du CERN sont crédités de l'invention du HTTP original, ainsi que du HTML et de la technologie associée 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 « WorldWideWeb », proposé pour la première fois en 1989, aujourd'hui connu sous le nom de World Wide Web .

Le premier serveur Web a été mis en service en 1990. Le protocole utilisé n'avait qu'une seule méthode, à savoir GET, qui demandait une page à un serveur. La réponse du serveur était toujours une page HTML.

En 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 à partir du serveur, mais ne prenant en charge aucun autre format de fichier ni téléchargement d'informations.

Depuis 1992, un nouveau document a été rédigé pour préciser l'évolution du protocole de base vers sa prochaine version complète. 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 qui incluait la version client HTTP. Il s'agissait du premier des nombreux brouillons non officiels de HTTP/1.0 qui ont précédé le travail final sur HTTP/1.0.

Après avoir décidé que de nouvelles fonctionnalités du protocole HTTP étaient nécessaires et qu'elles devaient être entièrement documentées sous forme de RFC officielles , au début de 1995, le groupe de travail HTTP (HTTP WG, dirigé par Dave Raggett ) a été constitué dans le but de normaliser et d'étendre le protocole avec des opérations étendues, une négociation étendue, des méta-informations plus riches, liées à un protocole de sécurité qui est devenu plus efficace en ajoutant des méthodes supplémentaires et des champs d'en-tête .

Le groupe de travail HTTP avait prévu de réviser et de publier de nouvelles versions du protocole sous les noms HTTP/1.0 et HTTP/1.1 dans le courant de 1995, mais, en raison des nombreuses révisions, ce calendrier a duré bien plus d'un an.

Le groupe de travail HTTP avait également prévu de spécifier une version 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é.

En mai 1996, la RFC 1945 a été publiée en tant que révision finale HTTP/1.0 de ce qui avait été utilisé au cours des 4 années précédentes comme projet HTTP/1.0 pré-standard qui était déjà utilisé par de nombreux navigateurs Web et serveurs Web.

Début 1996, les développeurs ont même commencé à inclure des extensions non officielles du protocole HTTP/1.0 (c'est-à-dire des connexions keep-alive, etc.) dans leurs produits en utilisant des brouillons des spécifications HTTP/1.1 à venir.

Depuis le début de l'année 1996, les principaux navigateurs Web et les développeurs de serveurs Web ont également commencé à implémenter de nouvelles fonctionnalités spécifiées par les spécifications préliminaires HTTP/1.1 pré-standard. L'adoption par l'utilisateur final des nouvelles versions de navigateurs et de serveurs a été rapide. En mars 1996, une société d'hébergement Web a signalé que plus de 40 % des navigateurs utilisés sur Internet utilisaient le nouvel en-tête HTTP/1.1 « Host » pour activer l'hébergement virtuel , et qu'en juin 1996, 65 % de tous les navigateurs accédant à leurs serveurs étaient conformes à la norme HTTP/1.1 pré-standard.

En janvier 1997, la RFC 2068 a été officiellement publiée en tant que spécifications HTTP/1.1.

En juin 1999, la RFC 2616 a été publiée pour inclure toutes les améliorations et mises à jour basées sur les spécifications HTTP/1.1 précédentes (obsolètes).

Reprenant le plan de 1995 du précédent groupe de travail HTTP, un groupe de travail HTTP-NG a été formé en 1997 pour développer un nouveau protocole HTTP appelé HTTP-NG (HTTP New Generation). Quelques propositions/projets ont été produits pour que le nouveau protocole utilise le multiplexage des transactions HTTP au sein d'une seule connexion TCP/IP, mais en 1999, le groupe a arrêté son activité en transmettant les problèmes techniques à l'IETF.

En 2007, le groupe de travail HTTP de l'IETF (HTTP WG bis ou HTTPbis) a été relancé, d'abord pour réviser et clarifier les spécifications HTTP/1.1 précédentes, puis pour rédiger et affiner les futures spécifications HTTP/2 (appelées httpbis).

En 2009, Google , une entreprise privée, a annoncé avoir développé et testé un nouveau protocole binaire HTTP nommé SPDY . L'objectif implicite était d'accélérer considérablement le trafic Web (en particulier entre les futurs navigateurs Web et ses serveurs).

SPDY était en effet beaucoup plus rapide que HTTP/1.1 dans de nombreux tests et il a donc été rapidement adopté par Chromium , puis par d'autres navigateurs Web majeurs.

Certaines des idées sur le multiplexage des flux HTTP sur une seule connexion TCP/IP proviennent de diverses sources, notamment des travaux du groupe de travail HTTP-NG du W3C.

En janvier-mars 2012, le groupe de travail HTTP (HTTPbis) a annoncé la nécessité de commencer à se concentrer sur un nouveau protocole HTTP/2 (tout en terminant la révision des spécifications HTTP/1.1), en prenant peut-être en considération les idées et le travail effectué pour SPDY.

Après quelques mois de réflexion sur la marche à suivre pour développer une nouvelle version de HTTP, il a été décidé de la dériver de SPDY.

En mai 2015, HTTP/2 a été publié sous la forme de RFC 7540 et rapidement adopté par tous les navigateurs Web prenant déjà en charge SPDY et plus lentement par les serveurs Web.

En juin 2014, le groupe de travail HTTP a publié une spécification HTTP/1.1 mise à jour en six parties rendant obsolète la RFC 2616 :

• RFC 7230, HTTP/1.1 : Syntaxe et routage des messages
• RFC 7231, HTTP/1.1 : sémantique et contenu
• RFC 7232, HTTP/1.1 : requêtes conditionnelles
• RFC 7233, HTTP/1.1 : requêtes de plage
• RFC 7234, HTTP/1.1 : mise en cache
• RFC 7235, HTTP/1.1 : Authentification

Dans la RFC 7230 Annexe-A, HTTP/0.9 a été déconseillé pour les serveurs prenant en charge la version HTTP/1.1 (et supérieure) :

Étant donné que HTTP/0.9 ne prend pas en charge les champs d'en-tête dans une requête, il n'existe aucun mécanisme lui permettant de prendre en charge les hôtes virtuels basés sur le nom (sélection de la ressource par inspection du champ d'en-tête Host). Tout serveur qui implémente des hôtes virtuels basés sur le nom doit désactiver la prise en charge de HTTP/0.9 . La plupart des requêtes qui semblent être HTTP/0.9 sont en fait des requêtes HTTP/1.x mal construites, causées par un client qui ne parvient pas à encoder correctement la cible de la requête.

Depuis 2016, de nombreux chefs de produits et développeurs d'agents utilisateurs (navigateurs, etc.) et de serveurs Web ont commencé à planifier l'abandon progressif et l'abandon de la prise en charge du protocole HTTP/0.9, principalement pour les raisons suivantes :

• c'est tellement simple qu'un document RFC n'a jamais été écrit (il n'y a que le document original) ;
• il n'a pas d'en-têtes HTTP et manque de nombreuses autres fonctionnalités qui sont aujourd'hui requises pour des raisons de sécurité minimales ;
• il n'est plus très répandu depuis 1999..2000 (à cause de HTTP/1.0 et HTTP/1.1) et n'est couramment utilisé que par certains matériels réseau très anciens, c'est-à-dire les routeurs , etc.

En 2020, les premiers projets de HTTP/3 ont été publiés et les principaux navigateurs et serveurs Web ont commencé à l'adopter.

Le 6 juin 2022, l'IETF a normalisé HTTP/3 sous la forme de RFC 9114.

En juin 2022, un lot de RFC a été publié, dépréciant de nombreux documents précédents et introduisant quelques modifications mineures et une refactorisation de la description de la sémantique HTTP dans un document séparé.

• RFC 9110, sémantique HTTP
• RFC 9111, mise en cache HTTP
• RFC 9112, HTTP/1.1
• RFC 9113, HTTP/2
• RFC 9114, HTTP/3 (voir également la section ci-dessus)
• RFC 9204, QPACK : compression de champ pour HTTP/3
• RFC 9218, Schéma de priorisation extensible pour HTTP

HTTP est un protocole de niveau application sans état et il nécessite une connexion de transport réseau fiable pour échanger des données entre le client et le serveur. Dans les implémentations HTTP, les connexions TCP/IP sont utilisées à l'aide de ports bien connus (généralement le port 80 si la connexion n'est pas chiffrée ou le port 443 si la connexion est chiffrée, voir également Liste des numéros de port TCP et UDP ). Dans HTTP/2, une connexion TCP/IP plus plusieurs canaux de protocole sont utilisés. Dans HTTP/3, le protocole de transport d'application QUIC sur UDP est utilisé.

Les données sont échangées via une séquence de messages de requête-réponse qui sont échangés par une connexion de transport de couche session . Un client HTTP essaie d'abord de se connecter à un serveur établissant une connexion (réelle ou virtuelle). Un serveur HTTP(S) à l'écoute sur ce port accepte la connexion puis attend le message de requête d'un client. Le client envoie son message de requête HTTP. À la réception de la requête, le serveur renvoie un message de réponse HTTP, qui comprend un ou plusieurs en-têtes plus un corps si nécessaire. Le corps de ce message de réponse est généralement la ressource demandée, bien qu'un message d'erreur ou d'autres informations puissent également être renvoyés. À tout moment (pour de nombreuses raisons), le client ou le serveur peut fermer la connexion. La fermeture d'une connexion est généralement annoncée à l'avance en utilisant un ou plusieurs en-têtes HTTP dans le dernier message de requête/réponse envoyé au serveur ou au client.

Dans HTTP/0.9 , la connexion TCP/IP est toujours fermée après l'envoi de la réponse du serveur, elle n'est donc jamais persistante.

Dans HTTP/1.0 , comme indiqué dans la RFC 1945, la connexion TCP/IP doit toujours être fermée par le serveur après l'envoi d'une réponse.

Dans HTTP/1.1, un mécanisme de maintien en vie a été officiellement introduit afin qu'une connexion puisse être réutilisée pour plusieurs requêtes/réponses. De telles connexions persistantes réduisent sensiblement la latence des requêtes car le client n'a pas besoin de renégocier la connexion TCP 3-Way-Handshake après l'envoi de la première requête. Un autre effet secondaire positif est que, en général, la connexion devient plus rapide avec le temps grâce au mécanisme de démarrage lent de TCP .

HTTP/1.1 a également ajouté le pipeline 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 vraiment sûre car quelques serveurs Web et de nombreux serveurs proxy , en particulier les serveurs proxy transparents placés sur Internet / Intranets entre les clients et les serveurs, ne géraient pas correctement les requêtes pipeline (ils ne servaient que la première requête en rejetant les autres, ils fermaient la connexion car ils voyaient plus de données après la première requête ou certains proxys renvoyaient même des 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 réels et donc avec des URL sans chaîne de requête utilisée comme commande, etc.) pouvaient être pipelined dans un mode sûr et idempotent. Après de nombreuses années de lutte contre les problèmes introduits par l'activation du pipeline, cette fonctionnalité a d'abord été désactivée puis supprimée de la plupart des navigateurs également en raison de l'adoption annoncée 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 (voir aussi : aperçu technique).

HTTP/0.9

Une ressource demandée a toujours été envoyée dans son intégralité.

HTTP/1.0

HTTP/1.0 a ajouté des en-têtes pour gérer les ressources mises en cache par le client afin de permettre les requêtes GET conditionnelles ; en pratique, un serveur doit renvoyer l'intégralité du contenu de la ressource demandée uniquement si sa dernière heure de modification n'est pas connue par le client ou si elle a changé depuis la dernière réponse complète à la requête GET. L'un de ces en-têtes, "Content-Encoding", a été ajouté pour spécifier si le contenu renvoyé d'une ressource était ou non compressé .

Si la longueur totale du contenu d'une ressource n'était pas connue à l'avance (parce qu'elle était générée dynamiquement, etc.), l'en-tête "Content-Length: number"n'était pas présent dans les en-têtes HTTP et le client supposait que lorsque le serveur fermait la connexion, le contenu avait été envoyé dans son intégralité. Ce mécanisme ne pouvait pas faire la distinction entre un transfert de ressource terminé avec succès et un transfert interrompu (à cause d'une erreur de serveur/réseau ou autre).

HTTP/1.1

HTTP/1.1 introduit :

• nouveaux en-têtes pour mieux gérer la récupération conditionnelle des ressources mises en cache.
• Encodage de transfert en morceaux permettant de diffuser du contenu en morceaux afin de l'envoyer de manière fiable même lorsque le serveur ne connaît pas sa longueur à l'avance (c'est-à-dire parce qu'il est généré dynamiquement, etc.).
• service de plage d'octets , où un client peut demander seulement une ou plusieurs parties (plages d'octets) d'une ressource (c'est-à-dire la première partie, une partie au milieu ou à la fin du contenu entier, etc.) et le serveur envoie généralement seulement la ou les parties demandées. Ceci est utile pour reprendre un téléchargement interrompu (lorsqu'un fichier est très volumineux), lorsque seule une partie d'un contenu doit être affichée ou ajoutée dynamiquement à la partie déjà visible par un navigateur (c'est-à-dire uniquement le premier ou les n commentaires suivants d'une page Web) afin d'économiser du temps, de la bande passante et des ressources système, etc.

HTTP/2, HTTP/3

HTTP/2 et HTTP/3 ont tous deux conservé les fonctionnalités mentionnées ci-dessus de HTTP/1.1.

HTTP fournit plusieurs schémas d'authentification tels que l'authentification d'accès de base et l'authentification d'accès digest qui fonctionnent via un mécanisme de défi-réponse par lequel le serveur identifie et émet un défi avant de fournir le contenu demandé.

HTTP fournit un cadre général pour le contrôle d'accès et l'authentification, via un ensemble extensible de schémas d'authentification de type challenge-réponse, qui peuvent être utilisés par un serveur pour contester une demande client et par un client pour fournir des informations d'authentification.

Les mécanismes d'authentification décrits ci-dessus appartiennent au protocole HTTP et sont gérés par les logiciels HTTP client et serveur (s'ils sont configurés pour exiger une authentification avant d'autoriser l'accès du client à une ou plusieurs ressources Web), et non par les applications Web utilisant une session d'application Web.

La spécification d'authentification HTTP fournit également une construction arbitraire, spécifique à l'implémentation, pour diviser davantage les ressources communes à un URI racine donné . La chaîne de valeur du domaine, si elle est présente, est combinée à l'URI racine canonique pour former le composant d'espace de protection du défi. Cela permet en effet au serveur de définir des portées d'authentification distinctes sous un URI racine.

HTTP est un protocole sans état . Un protocole sans état ne nécessite pas que le serveur Web conserve les informations ou le statut de chaque utilisateur pendant la durée de plusieurs requêtes.

Certaines applications Web doivent gérer les sessions utilisateur, elles implémentent donc des états, ou des sessions côté serveur , en utilisant par exemple des cookies HTTP des variables cachées dans les formulaires Web .

Pour démarrer une session utilisateur d'application, une authentification interactive via la connexion à l'application Web doit être effectuée. Pour arrêter une session utilisateur, une opération de déconnexion doit être demandée par l'utilisateur. Ces types d'opérations n'utilisent pas l'authentification HTTP mais une authentification d'application Web gérée personnalisée.

Les messages de requête sont envoyés par un client à un serveur cible.

Un client envoie des messages de requête au serveur, qui se composent de :

• une ligne de demande , composée de la méthode de demande sensible à la casse, d'un espace , de l'URI demandée, d'un autre espace, de la version du protocole, d'un retour chariot et d'un saut de ligne , par exemple :

OBTENIR 
/images/logo.png 
HTTP / 1.1

• zéro ou plusieurs champs d'en-tête de requête (au moins 1 ou plusieurs en-têtes dans le cas de HTTP/1.1), chacun composé du nom du champ insensible à la casse, de deux points, d'un espace de début facultatif , de la valeur du champ, d'un espace de fin facultatif et se terminant par un retour chariot et un saut de ligne, par exemple :

Hébergeur : www.example.com Accepter-Langue: fr 

• une ligne vide, composée d’un retour chariot et d’un saut de ligne ;
• un corps de message facultatif .

Dans le protocole HTTP/1.1, tous les champs d'en-tête, à l'exception Host: hostnamede sont facultatifs.

Une ligne de requête contenant uniquement le nom du chemin est acceptée par les serveurs pour maintenir la compatibilité avec les clients HTTP avant la spécification HTTP/1.0 dans la RFC 1945.

HTTP définit des méthodes (parfois appelées verbes , mais nulle part dans la spécification il n'est fait mention de verbe ) pour indiquer l'action souhaitée à effectuer sur la ressource identifiée. Ce que représente cette ressource, qu'il s'agisse de données préexistantes ou de données générées dynamiquement, dépend de l'implémentation du serveur. Souvent, la ressource correspond à un fichier ou à la sortie d'un exécutable résidant sur le serveur. La spécification HTTP/1.0 a défini les méthodes GET, HEAD et POST ainsi que la liste des méthodes PUT, DELETE, LINK et UNLINK sous des méthodes supplémentaires. Cependant, la spécification HTTP/1.1 a formellement défini et ajouté cinq nouvelles méthodes : PUT, DELETE, CONNECT, OPTIONS et TRACE. Tout client peut utiliser n'importe quelle méthode et le serveur peut être configuré pour prendre en charge n'importe quelle combinaison de méthodes. Si une méthode est inconnue d'un intermédiaire, elle sera traitée comme une méthode non sûre et non idempotente . Il n'y a pas de limite au nombre de méthodes qui peuvent être définies, ce qui permet de spécifier de futures méthodes sans perturber l'infrastructure existante. Par exemple, WebDAV a défini sept nouvelles méthodes et la RFC 5789 a spécifié la méthode PATCH .

Les noms de méthodes sont sensibles à la casse. Cela contraste avec les noms de champs d'en-tête HTTP qui ne sont pas sensibles à la casse.

OBTENIR

La méthode GET demande à la ressource cible de transférer une représentation de son état. Les requêtes GET ne doivent récupérer que des données et ne doivent avoir aucun autre effet. (Cela est également vrai pour certaines autres méthodes HTTP.) Pour récupérer des ressources sans apporter de modifications, GET est préférable à POST, car elles peuvent être adressées via une URL . Cela permet la mise en signet et le partage et rend les réponses GET éligibles à la mise en cache , ce qui peut économiser de la bande passante. Le W3C a publié des principes directeurs sur cette distinction, en disant : « La conception d'applications Web doit être informée par les principes ci-dessus, mais aussi par les limitations pertinentes. » Voir les méthodes sûres ci-dessous.

TÊTE

La méthode HEAD demande à la ressource cible de transférer une représentation de son état, comme pour une requête GET, mais sans les données de représentation incluses dans le corps de la réponse. Cela est utile pour récupérer les métadonnées de représentation dans l'en-tête de la réponse, sans avoir à transférer la représentation entière. Les utilisations incluent la vérification de la disponibilité d'une page via le code d'état et la recherche rapide de la taille d'un fichier ( Content-Length).

POSTE

La méthode POST demande à la ressource cible de traiter la représentation incluse dans la requête en fonction de la sémantique de la ressource cible. Par exemple, elle est utilisée pour publier un message sur un forum Internet , s'abonner à une liste de diffusion ou effectuer une transaction d'achat en ligne .

METTRE

La méthode PUT demande à la ressource cible de créer ou de mettre à jour son état avec l'état défini par la représentation incluse dans la requête. Une différence avec POST est que le client spécifie l'emplacement cible sur le serveur.

SUPPRIMER

La méthode DELETE demande à la ressource cible de supprimer son état.

CONNECTER

La méthode CONNECT demande à l'intermédiaire d'établir un tunnel TCP/IP vers le serveur d'origine identifié par la cible de la requête. Elle est souvent utilisée pour sécuriser les connexions via un ou plusieurs proxys HTTP avec TLS . Voir la méthode HTTP CONNECT .

OPTIONS

La méthode OPTIONS demande à la ressource cible de transférer les méthodes HTTP qu'elle prend en charge. Cela peut être utilisé pour vérifier la fonctionnalité d'un serveur Web en demandant '*' au lieu d'une ressource spécifique.

TRACER

La méthode TRACE demande à la ressource cible de transférer la requête reçue dans le corps de la réponse. De cette façon, un client peut voir quelles modifications ou quels ajouts (le cas échéant) ont été effectués par les intermédiaires.

CORRECTIF

La méthode PATCH demande à la ressource cible de modifier son état en fonction de la mise à jour partielle définie dans la représentation incluse dans la requête. Cela peut permettre d'économiser de la bande passante en mettant à jour une partie d'un fichier ou d'un document sans avoir à le transférer entièrement.

Tous les serveurs Web à usage général doivent implémenter au moins les méthodes GET et HEAD, et toutes les autres méthodes sont considérées comme facultatives par la spécification.

Une méthode de requête est sûre si une requête avec cette méthode n'a aucun effet prévu sur le serveur. Les méthodes GET, HEAD, OPTIONS et TRACE sont définies comme sûres. En d'autres termes, les méthodes sûres sont destinées à être en lecture seule . Les méthodes sûres peuvent toujours avoir des effets secondaires non visibles par le client, comme l'ajout d'informations de requête à un fichier journal ou le prélèvement 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 tels que l'envoi d'un e-mail . De telles méthodes ne sont donc généralement pas utilisées par les robots ou les robots d'indexation conformes ; certains qui ne sont pas conformes ont tendance à faire des requêtes sans tenir compte du contexte ou des conséquences.

Malgré la sécurité prescrite des requêtes GET, dans la pratique, leur traitement par le serveur n'est techniquement limité d'aucune façon. Une programmation négligente ou délibérément irrégulière peut permettre aux requêtes GET de provoquer des modifications non triviales sur le serveur. Cela est déconseillé en raison des problèmes qui peuvent survenir lorsque la mise en cache Web , les moteurs de recherche et d'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 en utilisant GET, supprimerait simplement l'article. Un site Web correctement codé nécessiterait une méthode DELETE ou POST pour cette action, ce que les robots non malveillants ne feraient pas.

Un exemple concret de ce phénomène s'est produit lors de la version bêta de courte durée de Google Web Accelerator , qui pré-récupérait des URL arbitraires sur la page consultée par un utilisateur, provoquant la modification ou la suppression automatique en masse des enregistrements . La version bêta a été suspendue quelques semaines seulement après sa première sortie, suite à de nombreuses critiques.

Une méthode de requête est idempotente si plusieurs requêtes identiques avec cette méthode ont le même effet qu'une seule requête de ce type. Les méthodes PUT et DELETE, ainsi que les méthodes sûres, sont définies comme idempotentes. Les méthodes sûres sont trivialement idempotentes, car elles sont censées n'avoir aucun effet sur le serveur ; les méthodes PUT et DELETE, quant à elles, sont idempotentes car les requêtes identiques successives seront ignorées. Un site Web peut, par exemple, configurer un point de terminaison PUT pour modifier l'adresse e-mail enregistrée d'un utilisateur. Si ce point de terminaison est configuré correctement, toutes les requêtes demandant de modifier l'adresse e-mail d'un utilisateur pour la même adresse e-mail déjà enregistrée (par exemple, des requêtes en double suite à une requête réussie) n'auront aucun effet. De même, une demande de SUPPRESSION d'un certain utilisateur n'aura aucun effet si cet utilisateur a déjà été supprimé.

En revanche, les méthodes POST, CONNECT et PATCH ne sont pas nécessairement idempotentes. Par conséquent, l'envoi d'une même requête POST plusieurs fois peut modifier davantage l'état du serveur ou avoir d'autres effets, comme l'envoi de plusieurs e-mails . Dans certains cas, il s'agit de l'effet souhaité, mais dans d'autres cas, cela peut se produire accidentellement. Un utilisateur peut, par exemple, envoyer par inadvertance plusieurs requêtes POST en cliquant à nouveau sur un bouton s'il n'a pas reçu de retour clair indiquant que le premier clic était en cours de traitement. Bien que les navigateurs Web puissent afficher des boîtes de dialogue d'alerte pour avertir les utilisateurs dans certains cas où le rechargement d'une page peut renvoyer une requête POST, il appartient généralement à l'application Web de gérer les cas où une requête POST ne doit pas être soumise plus d'une fois.

Notez que le fait qu'une méthode soit idempotente ou non n'est pas imposé par le protocole ou le serveur Web. Il est parfaitement possible d'écrire une application Web dans laquelle (par exemple) une insertion de base de données ou une autre action non idempotente est déclenchée par une requête GET ou autre. Cependant, le faire à l'encontre des recommandations peut entraîner des conséquences indésirables, si un agent utilisateur suppose que répéter la même requête est sûr alors que ce n'est pas le cas.

Une méthode de requête peut être mise en cache si les réponses aux requêtes avec cette méthode peuvent être stockées pour une réutilisation ultérieure. Les méthodes GET, HEAD et POST sont définies comme pouvant être mises en cache.

En revanche, les méthodes PUT, DELETE, CONNECT, OPTIONS, TRACE et PATCH ne peuvent pas être mises en cache.

Les champs d'en-tête de requête permettent au client de transmettre des informations supplémentaires au-delà de la ligne de requête, agissant comme des modificateurs de requête (de manière similaire aux paramètres d'une procédure). Ils donnent des informations sur le client, sur la ressource cible ou sur le traitement attendu de la requête.

Un message de réponse est envoyé par un serveur à un client en réponse à son ancien message de demande.

Un serveur envoie des messages de réponse au client, qui se composent de :

• une ligne d'état , composée de la version du protocole, d'un espace , du code d'état de la réponse , d'un autre espace, d'une phrase de raison éventuellement vide, d'un retour chariot et d'un saut de ligne , par exemple :

  HTTP / 1.1 
  200 
  OK
  

• zéro ou plusieurs champs d'en-tête de réponse , chacun composé du nom du champ insensible à la casse, de deux points, d' un espace de début facultatif , de la valeur du champ, d'un espace de fin facultatif et se terminant par un retour chariot et un saut de ligne, par exemple :

  Type de contenu : texte/html
  

• une ligne vide, composée d’un retour chariot et d’un saut de ligne ;
• un corps de message facultatif .

Dans HTTP/1.0 et depuis, la première ligne de la réponse HTTP est appelée ligne d'état et comprend un code d'état numérique (tel que « 404 ») et une phrase de raison textuelle (telle que « Not Found »). Le code d'état de la réponse est un code entier à trois chiffres représentant le résultat de la tentative du serveur de comprendre et de satisfaire la requête correspondante du client. La façon dont le client gère la réponse dépend principalement du code d'état et secondairement des autres champs d'en-tête de réponse. Les clients peuvent ne pas comprendre tous les codes d'état enregistrés, mais ils doivent comprendre leur classe (donnée par le premier chiffre du code d'état) et traiter un code d'état non reconnu comme étant équivalent au code d'état x00 de cette classe.

Les phrases de raison standard ne sont que des recommandations et peuvent être remplacées par des « équivalents locaux » à la discrétion du développeur Web . Si le code d'état indique un problème, l'agent utilisateur peut afficher la phrase de raison à l'utilisateur pour lui fournir des informations supplémentaires sur la nature du problème. La norme permet également à l'agent utilisateur de tenter d'interpréter la phrase de raison , bien que cela puisse être imprudent puisque la norme spécifie explicitement que les codes d'état sont lisibles par machine et les phrases de raison sont lisibles par l'homme.

Le premier chiffre du code d'état définit sa classe :

1XX(informatif)

La demande a été reçue, processus en cours.

2XX(réussi)

La demande a été reçue, comprise et acceptée avec succès.

3XX(réorientation)

D’autres mesures doivent être prises pour compléter la demande.

4XX(erreur client)

La demande contient une syntaxe incorrecte ou ne peut pas être satisfaite.

5XX(erreur de serveur)

Le serveur n'a pas réussi à répondre à une demande apparemment valide.

Les champs d'en-tête de réponse permettent au serveur de transmettre des informations supplémentaires au-delà de la ligne d'état, agissant comme des modificateurs de réponse. Ils donnent des informations sur le serveur ou sur un accès ultérieur à la ressource cible ou aux ressources associées.

Chaque champ d'en-tête de réponse a une signification définie qui peut être affinée par la sémantique de la méthode de demande ou du code d'état de réponse.

Vous trouverez ci-dessous un exemple de transaction HTTP entre un client HTTP/1.1 et un serveur HTTP/1.1 exécuté sur www.example.com , port 80.

GET 
/ 
HTTP / 1.1 
Hôte : 
www.example.com 
Agent utilisateur : 
Mozilla/5.0 
Accepter : 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 
Accepter-Language : 
en-GB,en;q=0.5 
Accepter-Encoding : 
gzip, deflate, br 
Connexion : 
keep-alive

Une requête client (constituée dans ce cas de la ligne de requête et de quelques en-têtes qui peuvent être réduits à l' "Host: hostname"en-tête uniquement) est suivie d'une ligne vide, de sorte que la requête se termine par une double fin de ligne, chacune sous la forme d'un retour chariot suivi d'un saut de ligne . La "Host: hostname"valeur d'en-tête fait la distinction entre plusieurs noms DNS partageant une seule adresse IP , ce qui permet un hébergement virtuel basé sur le nom . Bien qu'elle soit facultative dans HTTP/1.0, elle est obligatoire dans HTTP/1.1. (Une barre oblique "/" permet généralement de récupérer un fichier /index.html s'il y en a un.)

HTTP / 1.1 
200 
OK 
Date : 
Lun, 23 Mai 2005 22:38:34 GMT 
Type de contenu : 
text/html; charset=UTF-8 
Longueur du contenu : 
155 
Dernière modification : 
Mer, 08 Jan 2003 23:11:55 GMT 
Serveur : 
Apache/1.3.3.7 (Unix) (Red-Hat/Linux) 
ETag : 
"3f80f-1b6-3e1cb03b" 
Plages d'acceptation : 
octets 
Connexion : 
fermer
< html > 
< head > 
< title > Une page d'exemple </ title > 
</ head > 
< body > 
< p > Bonjour tout le monde, voici un document HTML très simple. </ p > 
</ body > 
</ html >

Le champ d'en-tête ETag"Content-Type" (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. spécifie le type de média Internet des données transmises par le message HTTP, tandis que "Content-Length"indique sa longueur en octets. Le serveur Web HTTP/1.1 publie sa capacité à répondre aux demandes pour certaines plages d'octets du document en définissant le champ "Accept-Ranges: bytes". Ceci est utile si le client n'a besoin que de certaines parties d'une ressource envoyée par le serveur, ce qui est appelé service d'octets . Lorsque "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 lignes d'en-tête sont facultatives, mais certaines sont obligatoires. Lorsque l'en-tête "Content-Length: number"est manquant dans une réponse avec un corps d'entité, cela doit être considéré comme une erreur dans HTTP/1.0, mais cela peut ne pas être une erreur dans HTTP/1.1 si l'en-tête "Transfer-Encoding: chunked"est présent. Le codage de transfert en bloc utilise une taille de bloc de 0 pour marquer la fin du contenu. Certaines anciennes implémentations de HTTP/1.0 omettaient l'en-tête "Content-Length"lorsque la longueur de l'entité du corps n'était pas connue au début de la réponse et donc le transfert de données vers le client continuait jusqu'à ce que le serveur ferme le socket.

Un peut être utilisé pour informer le client que la partie entité corps des données transmises est compressée par l'algorithme gzip. "Content-Encoding: gzip"

La méthode la plus courante pour établir une connexion HTTP chiffrée est HTTPS . Il existe également deux autres méthodes pour établir une connexion HTTP chiffrée : le protocole Secure Hypertext Transfer Protocol et l'utilisation de l' en-tête HTTP/1.1 Upgrade pour spécifier une mise à niveau vers TLS. La prise en charge par le navigateur de ces deux méthodes est cependant quasiment inexistante.

• Le protocole Gopher est un protocole de diffusion de contenu qui a été remplacé par HTTP au début des années 1990.
• Le protocole SPDY est une alternative à HTTP développée chez Google , remplacée par HTTP/2 .
• Le protocole Gemini est un protocole inspiré de Gopher qui impose des fonctionnalités liées à la confidentialité.