HTTP a des cookies HTTP. Les cookies permettent au serveur de suivre l'état de l'utilisateur, le nombre de connexions, la dernière connexion, etc.
HTTP a des connexions persistantes (Keep-Alive) où plusieurs requêtes peuvent être envoyées à partir de la même connexion TCP.
Même si plusieurs requêtes peuvent être envoyées sur la même connexion HTTP, le serveur n'attache aucune signification particulière au fait qu'elles arrivent sur le même socket. C'est uniquement une question de performance, visant à minimiser le temps/la bande passante qui serait sinon dépensé à rétablir une connexion pour chaque requête.
En ce qui concerne HTTP, ce sont toujours des requêtes distinctes et doivent contenir suffisamment d'informations pour remplir la demande. C'est là l'essence de la "sans état". Les requêtes ne seront pas associées les unes aux autres sans certaines informations partagées que le serveur connaît, ce qui dans la plupart des cas est un ID de session dans un cookie.
De Wikipedia:
HTTP est un protocole sans état. Un protocole sans état ne nécessite pas que le serveur conserve des informations ou un état sur chaque utilisateur pour la durée de multiples requêtes.
Mais certaines applications web peuvent devoir suivre la progression de l'utilisateur de page en page, par exemple lorsque qu'un serveur web est requis pour personnaliser le contenu d'une page web pour un utilisateur. Les solutions pour ces cas incluent:
- l'utilisation de cookies HTTP.
- sessions côté serveur,
- variables cachées (lorsque la page actuelle contient un formulaire), et
- la réécriture d'URL en utilisant des paramètres codés en URI, par exemple, /index.php?session_id=quelque_code_de_session_unique.
Ce qui rend le protocole sans état est que le serveur n'est pas obligé de suivre l'état sur de multiples requêtes, pas qu'il ne peut pas le faire s'il le souhaite. Cela simplifie le contrat entre le client et le serveur, et dans de nombreux cas (par exemple la fourniture de données statiques sur un CDN) minimise la quantité de données à transférer. Si les serveurs étaient obligés de maintenir l'état des visites des clients, la structure de l'émission et de la réponse aux requêtes serait plus complexe. Comme c'est le cas, la simplicité du modèle est l'une de ses plus grandes caractéristiques.
HTTP est appelé un protocole sans état car chaque requête est exécutée de manière indépendante, sans connaissance des requêtes qui ont été exécutées avant, ce qui signifie qu'une fois la transaction terminée, la connexion entre le navigateur et le serveur est également perdue.
Ce qui rend le protocole sans état est que dans sa conception originale, HTTP est un protocole de transfert de fichiers relativement simple:
Aucune relation n'était maintenue entre une connexion et une autre, même avec le même client. Cela simplifie le contrat entre le client et le serveur, et dans de nombreux cas, minimise la quantité de données devant être transférée.
Parce qu'un protocole sans état ne nécessite pas que le serveur retienne des informations de session ou de statut sur chaque partenaire de communication pour la durée de plusieurs requêtes.
HTTP est un protocole sans état, ce qui signifie que la connexion entre le navigateur et le serveur est perdue une fois la transaction terminée.
Avant que Netscape invente les cookies et le HTTPS en 1994, le HTTP pouvait être considéré comme stateless. Au fil du temps, de nombreux composants stateful ont été formellement ajoutés pour une myriade de raisons, y compris les performances et la sécurité. Mais les ajouts stateful n'étaient que des ajouts, il était donc toujours dit de manière familière que le HTTP était stateless car le noyau original cherchait explicitement à être stateless.
Alors que le HTTP/1 cherchait à l'origine à être stateless, de nombreux composants HTTP/2 sont la définition même de stateful. HTTP/2 a abandonné les objectifs stateless. Les composants stateful ne sont plus des "ajouts", mais des composants stateful sont définis dans le noyau de la norme HTTP/2. Il y a 125 références à "state" et zéro référence à "stateless" dans la spécification HTTP/2 (RFC 7540).
Voici une liste limitée, non exhaustive, de composants stateful de HTTP/1 et HTTP/2 :
La section 5.1 du RFC de HTTP/2 est un excellent exemple de mécanismes stateful définis par la norme HTTP/2.
Est-il sûr pour les applications web de considérer HTTP/2 comme un protocole stateless ?
HTTP/2 est un protocole stateful, mais votre application HTTP/2 peut ignorer les fonctionnalités stateful pour maintenir la statelessness.
Les applications existantes de HTTP/1 et HTTP/2 nécessitant un état se casseront si elles tentent de les utiliser sans état. Par exemple, il peut être impossible de se connecter à certains sites web HTTP/1.1 si les cookies sont désactivés, ce qui casse l'application. Il n'est peut-être pas sûr de supposer qu'une application HTTP/1 ou HTTP/2 particulière est sans état.
Les mécanismes stateful sont des ajouts ultérieurs au standard stateless original. Le HTTP/1 est familièrement dit être sans état, bien que dans la pratique nous utilisions des mécanismes stateful normalisés, comme les cookies et le cache. Contrairement au HTTP/1, le HTTP/2 définit des composants stateful dans sa norme dès le début. Une application HTTP/2 particulière peut utiliser un sous-ensemble des fonctionnalités de HTTP/2 pour maintenir la sans état, mais le protocole lui-même anticipe que l'état sera la norme, et non l'exception. L'erreur "HTTP est sans état" est un dogme ancien, loin de la réalité stateful moderne de HTTP et théoriquement, dans la pratique, vous utilisez le HTTP de manière stateful dans votre vie quotidienne.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
