Intenta comprender el código bien previamente a usarlo a tu trabajo y si ttienes algo que aportar puedes comentarlo.
Solución:
HTTP es un protocolo sin estado, en otras palabras, el servidor olvidará todo lo relacionado con el estado del cliente/navegador. Aunque las aplicaciones web han hecho que parezca virtualmente con estado.
Se puede obligar a un protocolo sin estado a comportarse como si tuviera estado. Esto se puede lograr si el servidor envía el estado al cliente, y si el cliente lo envía nuevamente al servidor, cada vez.
Hay tres formas en que esto se puede lograr en HTTP:
a) Uno son las cookies, en cuyo caso el estado se envía y se devuelve en encabezados HTTP.
b) La segunda es la extensión de URL, en cuyo caso el estado se envía como parte de la URL como respuesta.
c) El tercero son los “campos de formulario ocultos”, en los que el estado se envía al cliente como parte de la respuesta y se devuelve al servidor como parte de los datos ocultos de un formulario.
ESCALABILIDAD Y ALTA DISPONIBILIDAD
Una de las principales razones por las que HTTP escala tan bien es su apatridia. El protocolo sin estado alivia las preocupaciones de replicación, ya que el estado en sí no necesita almacenarse en el servidor.
Los protocolos con estado son lógicamente difíciles de implementar en Internet de manera confiable. Los servidores sin estado también son fácilmente escalables, mientras que la escalabilidad de los servidores con estado es problemática. La solicitud sin estado se puede enviar a cualquier nodo, en cualquier momento, mientras que con Stateful esto no es un caso.
HTTP como protocolo sin estado aumenta la disponibilidad de las aplicaciones web sin estado, que de otro modo serían difíciles o imposibles de implementar. Si se pierde la conexión, no se pierde ningún estado, el simple reenvío de la solicitud resolverá el problema. Las solicitudes sin estado también se pueden almacenar en caché.
ver más aquí
Ya que está preguntando acerca de una aplicación web, el protocolo siempre será sin estado: el protocolo para la web es http (o https), y eso es todo lo que ella escribió.
Creo que lo que está pensando es proporcionar un mecanismo de estado en su propia aplicación web. El enfoque típico para esto es que usted crea un identificador único para la sesión del usuario en su aplicación web (una ID de sesión de una forma u otra es la práctica común) que se transmite de un lado a otro entre el navegador y el servidor. Eso generalmente se hace en una cookie, aunque se puede hacer, con un poco más de molestia para usted dependiendo de su plataforma/marco, también en la URL.
Su código del lado del servidor almacena información con estado (nuevamente, generalmente llamada sesión del usuario) sin embargo, quiere usar el ID de sesión para buscarlo. los tráfico http simplemente devuelve el ID de sesión. Mientras ese identificador esté allí, cada transacción http es completamente independiente de todas las demás, por lo tanto, el tráfico del protocolo en sí no tiene estado.
HTTP es un stateless protocol. Todas las aplicaciones basadas en web también son stateless.
Cuando se envía una solicitud al servidor, se establece una conexión entre el cliente y el servidor. El servidor recibe la solicitud, procesa la solicitud y devuelve la respuesta y luego, la conexión se cerrará.
Si se envía otra solicitud, después de eso, se tratará como una nueva solicitud y se establecerá una nueva conexión.
Para hacer HTTP statefulusamos tecnicas de gestion de sesion. De modo que utiliza los datos provenientes de la solicitud anterior mientras procesa la solicitud actual, es decir, utiliza la misma conexión para una serie de interacciones entre el cliente y el servidor.
Las técnicas de gestión de sesión son:
- campo de formulario oculto
- Galleta
- sesión
- Reescritura de URL
valoraciones y reseñas
Acuérdate de que tienes autorización de explicar si te ayudó.