Alternativa HTTP
Cuando una red bloquea WebSocket, el chat continúa automáticamente mediante HTTPS normal: cuándo ocurre, cómo forzarlo, requisitos de la Content Security Policy y del proxy, y solución de problemas.
El widget normalmente se conecta al servidor del chat mediante WebSocket. Algunas redes no lo permiten. Para estos casos existe la alternativa HTTP: el chat continúa mediante solicitudes HTTPS normales, sin que usted ni sus visitantes tengan que hacer nada.
Qué es la alternativa HTTP
Las conexiones WebSocket suelen fallar:
- en redes empresariales cuyo proxy o cortafuegos solo permite solicitudes HTTP(S) normales,
- con proveedores de alojamiento, CDN o equilibradores de carga que no reenvían WebSocket,
- detrás de un proxy inverso que no transmite las cabeceras
UpgradeyConnection.
Con la alternativa HTTP, el widget recibe los mensajes del servidor como Server-Sent Events (un flujo HTTPS de larga duración). Si no llega nada por este flujo, cambia al sondeo largo. El envío utiliza HTTPS POST. Ambas vías transportan los mismos mensajes que WebSocket: sus visitantes escriben, reciben respuestas del asistente de IA y de sus agentes, y varias pestañas abiertas comparten una conexión como siempre. Los archivos adjuntos ya se suben mediante HTTPS y no dependen del tipo de conexión.
La alternativa se aplica al widget de chat de su sitio web. La interfaz de sus agentes sigue conectándose mediante WebSocket.
Cuándo se aplica
El widget utiliza la alternativa HTTP cuando
- el navegador no admite WebSocket,
- fallan dos intentos consecutivos de conexión WebSocket; un intento que no se ha establecido ni rechazado tras 8 segundos también cuenta como fallido,
- usted la fuerza (véase más abajo).
El cambio solo se produce mientras no se haya establecido ninguna conexión WebSocket en la página. Si se interrumpe una conexión WebSocket existente, por ejemplo al cambiar de red, el widget vuelve a conectarse mediante WebSocket.
Una vez activa la alternativa, el widget la mantiene en esta página. Para que las páginas siguientes no pierdan otros dos intentos, recuerda el cambio: las páginas abiertas en la misma pestaña en un plazo de 30 minutos se conectan directamente mediante HTTPS. Al mismo tiempo, el widget comprueba una vez por página, en segundo plano, si WebSocket ya puede pasar. Si es así, la página siguiente vuelve a utilizar WebSocket; la actual mantiene la alternativa HTTP.
Forzar la alternativa
Para pruebas o entornos donde se sabe que WebSocket no funciona, puede activar la alternativa HTTP desde el principio. La forma más sencilla es el atributo data-rc-transport="http" en la etiqueta de script del widget:
<script src="https://cdn.reactive.chat/loader.js"
data-rc-site-key="SITE_KEY"
data-rc-transport="http"
async></script>
El widget busca el atributo en todo el documento, por lo que también funciona en otro elemento si este ya está en el documento cuando arranca el widget.
Otra opción es establecerlo en JavaScript, antes de la etiqueta de script del widget:
<script>
window.ReactiveChatSettings = { transport: 'http' };
</script>
<script src="https://cdn.reactive.chat/loader.js"
data-rc-site-key="SITE_KEY"
async></script>
Una llamada posterior a ReactiveChat('boot', { transport: 'http' }) no tiene efecto: el tipo de conexión se fija al arrancar el widget.
Content Security Policy
Server-Sent Events, el sondeo largo y el envío utilizan la misma dirección que la conexión del chat, pero con https:// en lugar de wss://. Si su sitio define una Content Security Policy, connect-src debe permitir ambas formas:
connect-src 'self' wss://ws.reactive.chat https://ws.reactive.chat
El formulario sin conexión y las subidas de archivos también utilizan https:// como dirección. Con un dominio propio, se incluyen las direcciones de su subdominio:
connect-src 'self' wss://chat.your-domain.com https://chat.your-domain.com
Las demás entradas de su política no cambian. Los demás permisos necesarios se describen en Insertar el widget.
Con un dominio propio
Si el chat funciona a través de un subdominio de su sitio, la alternativa HTTP utiliza la misma ruta /rc_wss/ que WebSocket. Su proxy no necesita una ruta adicional, pero debe transmitir las respuestas de esta ruta sin almacenamiento en búfer:
- nginx:
proxy_buffering offyproxy_cache offen la sección/rc_wss/, - Apache:
flushpackets=onen la líneaProxyPassde/rc_wss/, - Caddy:
flush_interval -1en elreverse_proxyde/rc_wss/.
Las plantillas de la página de la cuenta y de la guía de dominio propio ya incluyen estos ajustes. Si utiliza una configuración antigua, compárela con la plantilla actual.
Qué se almacena en el navegador
Tras establecer una conexión HTTPS, el widget crea la entrada rc_http en sessionStorage del navegador. Solo contiene la hora de esa conexión, sin datos personales. La utiliza para que las páginas siguientes pasen directamente a la alternativa HTTP durante 30 minutos; cuando WebSocket vuelve a funcionar, elimina la entrada. Como cualquier entrada de sessionStorage, desaparece como muy tarde al cerrar la pestaña. Si sessionStorage no está disponible, por ejemplo en algunas ventanas privadas, cada página empieza de nuevo con WebSocket.
Qué vía está activa
Abra las herramientas de desarrollo del navegador y vaya a la pestaña «Red»:
- WebSocket: hay una conexión de tipo WebSocket a
wss://ws.reactive.chat/rc_wss/(con un dominio propio, a su subdominio). - Alternativa HTTP: hay solicitudes a
https://ws.reactive.chat/rc_wss/h/…– primeroh/auf, después un flujo de larga duración en…/sse(con sondeo largo, solicitudes recurrentes en…/poll) y una solicitud a…/txpor cada mensaje enviado.
En «Aplicación» o «Almacenamiento» también puede comprobar si existe la entrada rc_http.
Solución de problemas
La Content Security Policy bloquea la dirección https
Si connect-src solo incluye la dirección wss://, el navegador bloquea las solicitudes de la alternativa. La consola muestra entonces un mensaje CSP sobre https://…/rc_wss/h/auf. Donde WebSocket funciona no notará nada, pero en las redes sin WebSocket no se establece ninguna conexión. Añada la dirección https:// como se muestra arriba.
Un proxy almacena las respuestas en búfer
Si un proxy intermedio almacena el flujo en búfer, los Server-Sent Events llegan tarde, por lotes o no llegan. El widget espera 5 segundos al primer mensaje del flujo y después cambia al sondeo largo. El chat funciona así, pero tarda unos segundos más en conectarse. Con un dominio propio, desactive el almacenamiento en búfer de /rc_wss/ (véase arriba).
Se interrumpen las solicitudes largas
Con el sondeo largo, el servidor mantiene una solicitud abierta hasta 25 segundos cuando no hay nada que comunicar. En un flujo abierto envía una señal de mantenimiento cada 15 segundos. Los cortafuegos o proxys que interrumpen antes las solicitudes obligan al widget a reconectarse con frecuencia. Permita que las solicitudes a la dirección del chat duren al menos 30 segundos.
El chat no se conecta en absoluto
Si fallan tanto WebSocket como la alternativa HTTP, el widget sigue intentándolo en segundo plano. Compruebe si la dirección del chat es accesible mediante HTTPS desde la red de sus visitantes y si una Content Security Policy o un filtro la bloquea.
Más información en la documentación
En detalle: Transporte: WebSocket, alternativa HTTP y reconexión. Todos los capítulos están en la documentación.
Pēdējoreiz atjaunināts: