Le protocole HTTP pour Hyper Text Transfer Protocol à été défini au début des années 1990. A l'origine il était uniquement conçu pour transférer des pages Web au format HTML. Cependant il a connu diverses évolutions et il peut maintenant être utilisé pour transférer d'autres types de ressources (images, vidéos,
2.1 Présentation du protocole HTTP
code SQL obtenu après une requête effectuée auprès d’une base de données, demandes d’authentifications…). HTTP fonctionne suivant le modèle client / serveur où le navigateur Web est le client et une machine exécutant IIS, Apache ou bien encore Xitami est le serveur. Le port standard du protocole HTTP est le port 80 en TCP. Bien entendu, n’importe quel autre port TCP peut être utilisé par HTTP (8080, 8081). Une ressource Lambda peut être identifiée par une adresse ou URL (Uniform Ressource Locator).
Voici les diverses améliorations apportées au protocole HTTP au cours du temps :
• la v 0.9 n’est pas une version "commerciale", il s’agit uniquement des spécifications de base posées au début des années 90. Elle permet uniquement d’échanger des pages Web au format HTML.
• La v 1.0 a été normalisée en 1996 avec la RFC 1945. Elle permet d’envoyer n’importe quel type de ressource possédant un type MIME.
• La v 1.1 a été normalisée en 1997 avec la RFC 2068. Elle ajoute beaucoup de nouveautés par rapport à la version 1.0 (meilleurs débits car plusieurs ressources peuvent être transmises sur une seule connexion grâce aux connexions persistantes, temps d’accès améliorés grâce à une meilleure gestion du cache, plusieurs domaines peuvent coexister sur une même IP on parle de serveurs Web multisites, support des méthodes d’authentifications BASIC et DIGEST, support des images PNG et des feuilles de style CSS…).
• Quelques améliorations (ajout de nouvelles méthodes…) ont été apportées à certaines fonction en rapport avec le protocole HTTP, cependant la version actuelle est toujours la v1.1.
HTTP fonctionne avec un système de requête/réponse à l’instar de beaucoup d’autres protocoles (notamment LM, NTLM et Kerberos). Que le message soit une requête du client ou une réponse du serveur, il est constitué de trois parties : la ligne de requête/statut, l’en-tête et le corps. Dans certain cas, le message peut se passer de corps mais la ligne et l’en-tête, elles, sont toujours présentes ! Si vous souhaitez obtenir plus d’informations sur les différentes évolutions du protocole HTTP, vous pouvez consulter les RFCs suivantes : voir tableau 1.
Téléchargez cette ressource
Construire une infrastructure cloud optimisée pour l’IA avec Microsoft Azure
Les managers IT ont besoin d’une stratégie claire et de solutions concrètes pour préparer leur infrastructure cloud à l'adoption de l'IA, tout en optimisant les coûts, renforçant la sécurité et développant les compétences internes. Découvrez tous les conseils dans ce guide Insight.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Quand l’innovation échappe à ses créateurs: Comment éviter l’effet Frankenstein à l’ère de l’IA
- L’IA agentique, nouveau pilier de la résilience numérique des RSSI
- L’identité, talon d’Achille de la cybersécurité
- De la donnée brute à l’actif stratégique : une approche produit
Articles les + lus
Confiance et curiosité : les clés pour entrer (et grandir) en tant que femme dans la tech
Portails développeurs internes : accélérer l’innovation sans alourdir les budgets
Pourquoi Shopify Plus s’impose dans la transformation du e-commerce B2B
Quand l’innovation échappe à ses créateurs: Comment éviter l’effet Frankenstein à l’ère de l’IA
Alliée ou menace ? Comment l’IA redessine le paysage cyber
À la une de la chaîne Tech
- Confiance et curiosité : les clés pour entrer (et grandir) en tant que femme dans la tech
- Portails développeurs internes : accélérer l’innovation sans alourdir les budgets
- Pourquoi Shopify Plus s’impose dans la transformation du e-commerce B2B
- Quand l’innovation échappe à ses créateurs: Comment éviter l’effet Frankenstein à l’ère de l’IA
- Alliée ou menace ? Comment l’IA redessine le paysage cyber
