Repli HTTP

Le widget se connecte normalement au serveur de chat par WebSocket. Certains réseaux ne l’autorisent pas. Le repli HTTP permet alors au chat de continuer à fonctionner avec des requêtes HTTPS ordinaires, sans intervention de votre part ni de celle de vos visiteurs.

Qu’est-ce que le repli HTTP ?

Les connexions WebSocket échouent généralement :

• dans les réseaux d’entreprise dont le proxy ou le pare-feu n’autorise que les requêtes HTTP(S) ordinaires,
• chez les hébergeurs, CDN ou répartiteurs de charge qui ne transmettent pas les connexions WebSocket,
• derrière un proxy inverse qui ne transmet pas les en-têtes Upgrade et Connection.

En repli HTTP, le widget reçoit les messages du serveur sous forme de Server-Sent Events, un flux HTTPS qui reste ouvert longtemps. Si aucun message n’arrive par ce flux, il passe à l’interrogation longue (long polling). L’envoi utilise des requêtes HTTPS POST. Ces deux modes transportent les mêmes messages que WebSocket : vos visiteurs écrivent, reçoivent les réponses de l’assistant IA et de vos agents, et plusieurs onglets ouverts partagent une seule connexion, comme d’habitude. Les pièces jointes sont de toute façon envoyées par HTTPS et ne dépendent pas du type de connexion.

Le repli concerne le widget de chat sur votre site. L’espace agents continue de se connecter par WebSocket.

Quand s’active-t-il ?

Le widget utilise le repli HTTP lorsque

• le navigateur ne prend pas en charge WebSocket,
• deux tentatives de connexion WebSocket échouent consécutivement ; une tentative qui n’a été ni établie ni rejetée après 8 secondes compte également comme un échec,
• vous le forcez (voir ci-dessous).

Le changement ne se produit que si aucune connexion WebSocket n’a encore été établie sur la page. Si une connexion WebSocket existante est interrompue, par exemple lors d’un changement de réseau, le widget se reconnecte par WebSocket.

Une fois le repli activé, le widget le conserve pour cette page. Pour éviter deux nouvelles tentatives infructueuses sur les pages suivantes, il mémorise ce changement : les pages ouvertes dans le même onglet dans les 30 minutes se connectent directement par HTTPS. En parallèle, le widget vérifie une fois par page, en arrière-plan, si une connexion WebSocket peut désormais aboutir. Si c’est le cas, la page suivante utilise de nouveau WebSocket ; la page actuelle reste en repli HTTP.

Forcer le repli

Pour les tests ou dans les environnements où vous savez que WebSocket ne fonctionne pas, vous pouvez activer le repli HTTP dès le départ. Le plus simple est d’ajouter l’attribut data-rc-transport="http" à la balise script du widget :

<script src="https://cdn.reactive.chat/loader.js"
        data-rc-site-key="SITE_KEY"
        data-rc-transport="http"
        async></script>

Le widget recherche cet attribut dans tout le document. Il fonctionne donc aussi sur un autre élément, à condition que celui-ci soit déjà présent dans le document au démarrage du widget.

Vous pouvez aussi définir l’option en JavaScript, avant la balise script du widget :

<script>
  window.ReactiveChatSettings = { transport: 'http' };
</script>
<script src="https://cdn.reactive.chat/loader.js"
        data-rc-site-key="SITE_KEY"
        async></script>

Un appel ultérieur à ReactiveChat('boot', { transport: 'http' }) n’a aucun effet à cet égard : le type de connexion est fixé au démarrage du widget.

Content Security Policy

Les Server-Sent Events, l’interrogation longue et l’envoi utilisent la même adresse que la connexion du chat, avec https:// à la place de wss://. Si votre site définit une Content Security Policy, connect-src doit donc autoriser les deux formes :

connect-src 'self' wss://ws.reactive.chat https://ws.reactive.chat

Le formulaire hors ligne et l’envoi de fichiers utilisent aussi l’adresse https:// pour communiquer. Avec un domaine personnalisé, indiquez les adresses de votre sous-domaine :

connect-src 'self' wss://chat.your-domain.com https://chat.your-domain.com

Les autres directives de votre politique restent inchangées. Les autres autorisations nécessaires sont décrites dans Intégrer le widget.

Avec un domaine personnalisé

Si vous faites passer le chat par un sous-domaine de votre site, le repli HTTP utilise le même chemin /rc_wss/ que WebSocket. Votre proxy n’a pas besoin de chemin supplémentaire, mais il doit transmettre les réponses sur ce chemin sans mise en tampon :

• nginx : proxy_buffering off et proxy_cache off dans la section /rc_wss/,
• Apache : flushpackets=on sur la ligne ProxyPass pour /rc_wss/,
• Caddy : flush_interval -1 dans le reverse_proxy pour /rc_wss/.

Les modèles de la page du compte et du guide du domaine personnalisé contiennent déjà ces réglages. Si vous avez repris une ancienne configuration, comparez-la au modèle actuel.

Ce qui est stocké dans le navigateur

Après une connexion HTTPS réussie, le widget crée l’entrée rc_http dans le sessionStorage du navigateur. Elle contient uniquement l’heure de cette connexion, sans données personnelles. Le widget l’utilise pour que les pages suivantes passent directement au repli HTTP pendant 30 minutes ; dès que WebSocket fonctionne de nouveau, il supprime cette entrée. Comme toute entrée de sessionStorage, elle disparaît au plus tard à la fermeture de l’onglet. Si sessionStorage n’est pas disponible, par exemple dans certaines fenêtres privées, chaque page commence de nouveau par WebSocket.

Quel mode est actif ?

Ouvrez les outils de développement du navigateur, puis l’onglet « Réseau » :

• WebSocket : une connexion de type WebSocket apparaît vers wss://ws.reactive.chat/rc_wss/ (vers votre sous-domaine si vous utilisez un domaine personnalisé).
• Repli HTTP : des requêtes apparaissent vers https://ws.reactive.chat/rc_wss/h/… : d’abord h/auf, puis un flux de longue durée sur …/sse (avec l’interrogation longue, des requêtes répétées sur …/poll) et une requête sur …/tx pour chaque message envoyé.

Dans « Application » ou « Stockage », vous pouvez aussi vérifier si l’entrée rc_http est présente.

Dépannage

La Content Security Policy bloque l’adresse https

Si connect-src ne contient que l’adresse wss://, le navigateur bloque les requêtes du repli. La console du navigateur affiche alors un message CSP concernant https://…/rc_wss/h/auf. Vous ne remarquerez rien là où WebSocket fonctionne, mais aucune connexion ne sera établie dans les réseaux sans WebSocket. Ajoutez l’adresse https:// comme indiqué plus haut.

Un proxy met les réponses en tampon

Si un proxy intermédiaire met le flux en tampon, les Server-Sent Events arrivent en retard, par lots, voire pas du tout. Le widget attend le premier message du flux pendant 5 secondes, puis passe à l’interrogation longue. Le chat fonctionne ainsi, mais l’établissement de la connexion prend quelques secondes de plus. Avec un domaine personnalisé, désactivez la mise en tampon pour /rc_wss/ (voir plus haut).

Les requêtes de longue durée sont interrompues

Avec l’interrogation longue, le serveur garde une requête ouverte jusqu’à 25 secondes lorsqu’il n’a rien à signaler. Sur un flux ouvert, il envoie un signal de maintien de connexion toutes les 15 secondes. Les pare-feu ou les proxys qui interrompent les requêtes plus tôt obligent le widget à se reconnecter souvent. Autorisez des requêtes d’au moins 30 secondes vers l’adresse du chat.

Le chat ne se connecte pas du tout

Si WebSocket et le repli HTTP échouent tous deux, le widget continue ses tentatives en arrière-plan. Vérifiez si l’adresse du chat est accessible par HTTPS depuis le réseau de vos visiteurs et si une Content Security Policy ou un filtre la bloque.

Pour en savoir plus dans la documentation

Pour approfondir : Transport : WebSocket, repli HTTP et reconnexion. Retrouvez tous les chapitres dans la documentation.