L’, généralement abrégé HTTP, littéralement « protocole de transfert hypertexte », est un protocole de communication client-serveur développé pour le . HTTPS (avec S pour , soit « sécurisé ») est la variante sécurisée par le chiffrement et l'authentification.
HTTP est, avec HTML et les URL, une des trois inventions fondamentales de Tim Berners-Lee pour créer le World Wide Web.
Les clients HTTP les plus connus sont les navigateurs Web. HTTP est aussi utilisé hors du Web pour mettre en œuvre les interfaces de programmation distribuée fondées sur SOAP et REST.
Historique
HTTP a été inventé par Tim Berners-Lee avec les adresses Web et le langage HTML pour créer le World Wide Web. À cette époque, le (FTP) était déjà disponible pour transférer des fichiers, mais il ne supportait pas la notion de format de données telle qu'introduite par (MIME). La première version de HTTP était très élémentaire, mais prévoyait déjà le support d'en-têtes MIME pour décrire les données transmises. Cette première version reste encore partiellement utilisable de nos jours, connue sous le nom de HTTP/0.9.
En , la décrit HTTP tel que communément implémenté à l'époque et connu sous le nom de HTTP/1.0. Cette version supporte la gestion de cache et l'identification.
En , HTTP/1.1 devient finalement standard de l'IETF. Il est décrit dans la de l'IETF, puis dans la en . Cette version ajoute le support du transfert en pipeline (ou pipelinage) et la négociation de type de contenu (format de données, langue). HTTP/1.1 rend la présence de l'entête Host obligatoire dans les requêtes afin de supporter l'hébergement mutualisé.
En , les travaux à propos de HTTP/2.0 démarrent à l'IETF adoptant SPDY comme matériel de départ. Le protocole sera publié en la .
En , la spécification de HTTP 1.1 a été republiée. Elle a été éclatée en plusieurs RFC et corrigée pour toutes ses imprécisions, à .
Implémentation
Méthodes thumb|400px|Capture d'écran d'une requête GET et de sa réponse. Dans le protocole HTTP, une méthode est une commande spécifiant un type de requête, c'est-à-dire qu'elle demande au serveur d'effectuer une action. En général l'action concerne une ressource identifiée par l'URL qui suit le nom de la méthode.
Dans l'illustration ci-contre, une requête GET est envoyée pour récupérer la page d'accueil du site web www.perdu.com : GET / HTTP/1.1 Host: www.perdu.com
Il existe de nombreuses méthodes, les plus courantes étant GET, HEAD et POST : GETC'est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet. HEADCette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même. POSTCette méthode est utilisée pour transmettre des données en vue d'un traitement à une ressource (le plus souvent depuis un formulaire HTML). L'URI fourni est l'URI d'une ressource à laquelle s'appliqueront les données envoyées. Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP (pour Ajax) par certains navigateurs (et la norme HTML qui ne supporte que les méthodes GET et POST pour les formulaires), cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée pour la mise à jour de ressources. OPTIONSCette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général. CONNECTCette méthode permet d'utiliser un proxy comme un tunnel de communication. TRACECette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion. PUTCette méthode permet de remplacer ou d'ajouter une ressource sur le serveur. L'URI fourni est celui de la ressource en question. PATCHCette méthode permet, contrairement à PUT, de faire une modification partielle d'une ressource. DELETECette méthode permet de supprimer une ressource du serveur. Ces 3 dernières méthodes nécessitent généralement un accès privilégié.
Certains serveurs autorisent d'autres méthodes de gestion de leurs ressources (par exemple WebDAV).
Du client au serveur La liaison entre le client et le serveur n'est pas toujours directe, il peut exister des machines intermédiaires servant de relais : un proxy (ou serveur mandataire) peut modifier les réponses et requêtes qu'il reçoit et peut gérer un cache des ressources demandées, une passerelle (ou ) est un intermédiaire modifiant le protocole utilisé, un tunnel transmet les requêtes et les réponses sans aucune modification, ni mise en cache.
Identification HTTP permet l'identification du visiteur par transmission d'un nom et d'un mot de passe. Il existe deux modes d'identification : et (). Le premier mode transmet le mot de passe en clair et ne doit donc être utilisé qu'avec le protocole HTTPS. Le deuxième mode permet une identification sans transmettre le mot de passe en clair. L'identification est, cependant souvent effectuée par une couche applicative supérieure à HTTP.
Liste de serveurs HTTP
C : Apache, Zeus Web Server, nginx, lighttpd, Cherokee, Hiawatha Webserver ASP/ASP.Net(C#, VB.net) : IIS Java : Tomcat, Jetty, GlassFish, JBoss (WildFly dans les nouvelles versions), JOnAS, Vert.x Python : Zope Pike : Caudium Ruby : WEBrick, Mongrel, Thin. Erlang : Yaws Javascript : Express.js Autres : Comparison of web servers
Versions
HTTP 0.9 Au début du , il était prévu d'ajouter au protocole HTTP des capacités de négociation de contenu, en s'inspirant notamment de MIME. En attendant, le protocole HTTP 0.9 était extrêmement simple. connexion du client HTTP envoi d'une requête de méthode GET réponse du serveur HTTP le serveur ferme la connexion pour signaler la fin de la réponse Requête : GET /page.html La méthode GET est la seule possible. Le serveur reconnaît qu'il a affaire à une requête HTTP 0.9 au fait que la version n'est pas précisée à la suite de l'URI.
Réponse : <TITLE>Exemple</TITLE> <H1>Exemple</H1>Ceci est une page d'exemple. Pour répondre à une requête HTTP 0.9, le serveur envoie directement le contenu de la réponse, sans métadonnées. Il ne doit jamais se comporter ainsi pour les requêtes HTTP de version supérieure.
Inutile de chercher les versions inférieures à 0.9 du protocole HTTP : elles n'existent pas, car HTTP 0.9 n'avait initialement pas de numéro de version. Il a fallu lui en attribuer un quand HTTP 1.0 est arrivé.
HTTP 1.0 Le protocole HTTP 1.0, décrit dans la , prévoit l'utilisation d'en-têtes spécifiés dans la . La gestion de la connexion reste identique à HTTP 0.9 : le client établit la connexion, envoie une requête, le serveur répond et ferme immédiatement la connexion.
Une requête HTTP présente le format suivant :
Ligne de commande (Commande, URL, Version de protocole) En-tête de requête [Ligne vide] Corps de requête
Les réponses HTTP présentent le format suivant :
Ligne de statut (Version, Code-réponse, Texte-réponse) En-tête de réponse [Ligne vide] Corps de réponse
Requête : GET /page.html HTTP/1.0 Host: example.com Referer: http://example.com/ User-Agent: CERN-LineMode/2.15 libwww/2.17b3
La version du protocole HTTP est précisée à la suite de l'URI. La requête doit être terminée par un double retour à la ligne (CRLFCRLF). HTTP 1.0 supporte aussi les méthodes HEAD et POST. On constate l'usage d'en-têtes inspirés de MIME pour transférer les métadonnées : HostPermet de préciser le site web concerné par la requête, ce qui est nécessaire pour un serveur hébergeant plusieurs sites à la même adresse IP (, hôte virtuel basé sur le nom). C'est le seul en-tête réellement important. RefererIndique l'URI du document qui a donné un lien sur la ressource demandée. Cet en-tête permet aux d'observer d'où viennent les visiteurs. User-AgentIndique le logiciel utilisé pour se connecter. Il s'agit généralement d'un navigateur web ou d'un robot d'indexation.
Réponse : HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Server: Apache/0.8.4 Content-Type: text/html Content-Length: 59 Expires: Sat, 01 Jan 2000 00:59:59 GMT Last-modified: Fri, 09 Aug 1996 14:21:40 GMT
<TITLE>Exemple</TITLE> <P>Ceci est une page d'exemple.</P>
La première ligne donne le code de statut HTTP (200 dans ce cas). DateMoment auquel le message est généré. ServerIndique quel modèle de serveur HTTP répond à la requête. Content-TypeIndique le type MIME de la ressource. Content-LengthIndique la taille en octets de la ressource. ExpiresIndique le moment après lequel la ressource devrait être considérée obsolète ; permet aux navigateurs Web de déterminer jusqu'à quand garder la ressource en mémoire cache. Last-ModifiedIndique la date de dernière modification de la ressource demandée.
HTTP 1.1 Le protocole HTTP 1.1 est décrit par le qui rend le obsolète. La différence avec HTTP 1.0 est une meilleure gestion du cache. L'en-tête devient obligatoire dans les requêtes.
Les soucis majeurs des deux premières versions du protocole HTTP sont d'une part le nombre important de connexions lors du chargement d'une page complexe (contenant beaucoup d'images ou d'animations) et d'autre part le temps d'ouverture d'une connexion entre client et serveur (l'établissement d'une connexion TCP prend un temps triple de la latence entre client et serveur). Des expérimentations de connexions persistantes ont cependant été effectuées avec HTTP 1.0 (notamment par l'emploi de l'en-tête ), mais cela n'a été définitivement mis au point qu'avec HTTP 1.1.
Par défaut, HTTP 1.1 utilise des connexions persistantes, autrement dit la connexion n'est pas immédiatement fermée après une requête, mais reste disponible pour une nouvelle requête. On appelle souvent cette fonctionnalité . Il est aussi permis à un client HTTP d'envoyer plusieurs requêtes sur la même connexion sans attendre les réponses. On appelle cette fonctionnalité . La persistance des connexions permet d'accélérer le chargement de pages contenant plusieurs ressources, tout en diminuant la charge du réseau.
La gestion de la persistance d'une connexion est gérée par l'en-tête .
HTTP 1.1 supporte la négociation de contenu. Un client HTTP 1.1 peut accompagner la requête pour une ressource d'en-têtes indiquant quels sont les langues et formats de données préférés. Il s'agit des en-têtes dont le nom commence par .
Les en-têtes supplémentaires supportés par HTTP 1.1 sont : ConnectionCet en-tête peut être envoyé par le client ou le serveur et contient une liste de noms spécifiant les options à utiliser avec la connexion actuelle. Si une option possède des paramètres ceux-ci sont spécifiés par l'en-tête portant le même nom que l'option ( par exemple, pour spécifier le nombre maximum de requêtes par connexion). Le nom est réservé pour spécifier que la connexion doit être fermée après traitement de la requête en cours. AcceptCet en-tête liste les types MIME de contenu acceptés par le client. Le caractère étoile * peut servir à spécifier tous les types / sous-types. Accept-CharsetSpécifie les encodages de caractères acceptés. Accept-LanguageSpécifie les langues acceptées.
L'ordre de préférence de chaque option (type, encodage ou langue) est spécifié par le paramètre optionnel q contenant une valeur décimale entre 0 () et 1 () inclus (3 décimales maximum après la virgule), valant 1 par défaut.
Le support des connexions persistantes doit également fonctionner dans les cas où la taille de la ressource n'est pas connue d'avance (ressource générée dynamiquement par le serveur, flux externe au serveur…).
Pour cela, l'encodage de transfert nommé permet de transmettre la ressource par morceaux consécutifs en précédant chacun par une ligne de texte donnant la taille de celui-ci en hexadécimal. Le transfert se termine alors par un morceau de taille nulle, où des en-têtes finaux peuvent être envoyés.
Les en-têtes supplémentaires liés à cet encodage de transfert sont :