Te sugerimos que pruebes esta solución en un entorno controlado antes de pasarlo a producción, saludos.
Aunque se pueden enviar varias solicitudes a través de la misma conexión HTTP, el servidor no atribuye ningún significado especial a que lleguen a través del mismo socket. Eso es únicamente una cuestión de rendimiento, con la intención de minimizar el tiempo/ancho de banda que de otro modo se gastaría en restablecer una conexión para cada solicitud.
En lo que respecta a HTTP, todas siguen siendo solicitudes separadas y deben contener suficiente información por sí mismas para cumplir con la solicitud. Esa es la esencia de la “apatridia”. Las solicitudes no se asociarán entre sí en ausencia de información compartida que el servidor conozca, que en la mayoría de los casos es una ID de sesión en una cookie.
De Wikipedia:
HTTP es un protocolo sin estado. Un protocolo sin estado no requiere que el servidor retenga información o estado sobre cada usuario durante la duración de múltiples solicitudes.
Pero algunas aplicaciones web pueden tener que seguir el progreso del usuario de una página a otra, por ejemplo, cuando se requiere un servidor web para personalizar el contenido de una página web para un usuario. Las soluciones para estos casos incluyen:
- el uso de cookies HTTP.
- sesiones del lado del servidor,
- variables ocultas (cuando la página actual contiene un formulario), y
- Reescritura de URL utilizando parámetros codificados por URI, por ejemplo, /index.php?session_id=some_unique_session_code.
Lo que hace que el protocolo sea apátrida es que el servidor no está requerido para rastrear el estado de múltiples solicitudes, no es que no pueda hacerlo si así lo desea. Esto simplifica el contrato entre el cliente y el servidor y, en muchos casos (por ejemplo, sirviendo static datos a través de un CDN) minimiza la cantidad de datos que deben transferirse. Si los servidores fueran requerido para mantener el estado de las visitas de los clientes, la estructura de emisión y respuesta a las solicitudes sería más compleja. Tal como está, la sencillez del modelo es una de sus mayores características.
Porque un protocolo sin estado no requiere que el servidor conserve la información de la sesión o el estado de cada socio de comunicaciones durante la duración de varias solicitudes.
HTTP es un protocolo sin estado, lo que significa que la conexión entre el navegador y el servidor se pierde una vez que finaliza la transacción.
Si sostienes algún recelo o forma de regenerar nuestro post puedes ejecutar un exégesis y con gusto lo estudiaremos.