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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Analyse Patch Tuesday Mai 2026
- Pour un cloud plus fiable : renforcer l’auditabilité et la transparence au service de la sécurité
- Explosion des identités et insécurité persistante : l’EMEA face à un tournant critique
- ALERTE ! De nouvelles générations de cybermenaces dopées à l’IA
Articles les + lus
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
À la une de la chaîne Tech
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
