HTTP-fallback

De widget maakt normaal via WebSocket verbinding met de chatserver. Sommige netwerken staan dat niet toe. Daarvoor is er de HTTP-fallback: de chat werkt dan verder via gewone HTTPS-verzoeken, zonder dat u of uw bezoekers iets hoeven te doen.

Wat de HTTP-fallback is

WebSocket-verbindingen mislukken doorgaans:

• in bedrijfsnetwerken waarvan de proxy of firewall alleen gewone HTTP(S)-verzoeken doorlaat,
• bij hostingproviders, CDN’s of loadbalancers die geen WebSockets doorsturen,
• achter een reverse proxy die de headers Upgrade en Connection niet doorgeeft.

Bij de HTTP-fallback ontvangt de widget de berichten van de server als Server-Sent Events (een langdurig open HTTPS-stream). Komt er via die stream niets binnen, dan schakelt de widget over op long polling. Verzenden gebeurt via HTTPS POST. Beide routes vervoeren dezelfde berichten als de WebSocket: uw bezoekers schrijven, krijgen antwoord van de AI-assistent en uw medewerkers, en meerdere geopende tabbladen delen zoals gewoonlijk één verbinding. Bestandsbijlagen worden sowieso via HTTPS geüpload en zijn onafhankelijk van het verbindingstype.

De fallback geldt voor de chatwidget op uw website. De interface van uw medewerkers maakt nog steeds via WebSocket verbinding.

Wanneer de fallback wordt gebruikt

De widget gebruikt de HTTP-fallback als

• de browser geen WebSockets ondersteunt,
• twee opeenvolgende pogingen om via WebSocket verbinding te maken mislukken — ook een poging die na 8 seconden nog niet tot stand is gekomen en evenmin is afgewezen, telt als mislukt,
• u de fallback afdwingt (zie hieronder).

Er wordt alleen overgeschakeld zolang er op de pagina nog geen WebSocket-verbinding tot stand is gekomen. Valt een bestaande WebSocket-verbinding weg, bijvoorbeeld door een netwerkwissel, dan maakt de widget opnieuw via WebSocket verbinding.

Zodra de fallback actief is, blijft de widget deze op de huidige pagina gebruiken. Om op volgende pagina’s niet opnieuw twee pogingen te verliezen, onthoudt de widget de omschakeling: pagina’s die binnen 30 minuten in hetzelfde tabblad worden geopend, maken direct via HTTPS verbinding. Tegelijk controleert de widget eenmaal per pagina op de achtergrond of een WebSocket inmiddels wordt doorgelaten. Lukt dat, dan gebruikt de volgende pagina weer WebSocket; de huidige pagina blijft de HTTP-fallback gebruiken.

De fallback afdwingen

Voor tests of in omgevingen waarvan bekend is dat WebSockets er niet werken, kunt u de HTTP-fallback meteen inschakelen. Het eenvoudigst is het attribuut data-rc-transport="http" op de scripttag van de widget:

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

De widget zoekt het attribuut in het hele document. Het werkt dus ook op een ander element, zolang dat element al in het document staat wanneer de widget start.

U kunt de optie ook via JavaScript instellen, vóór de scripttag van de widget:

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

Een latere aanroep van ReactiveChat('boot', { transport: 'http' }) heeft hierop geen invloed: het verbindingstype wordt vastgelegd wanneer de widget start.

Content Security Policy

Server-Sent Events, long polling en het verzenden gebruiken hetzelfde adres als de chatverbinding, maar met https:// in plaats van wss://. Als uw website een Content Security Policy instelt, moet connect-src daarom beide vormen toestaan:

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

Het adres met https:// wordt ook gebruikt voor het offlineformulier en bestandsuploads. Bij een eigen domein vult u daar de adressen van uw subdomein in:

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

Andere onderdelen van uw beleid blijven ongewijzigd. Wat het beleid verder moet toestaan, staat in De widget insluiten.

Met een eigen domein

Als u de chat via een subdomein van uw website laat lopen, gebruikt de HTTP-fallback hetzelfde pad /rc_wss/ als de WebSocket. Uw proxy heeft daarvoor geen extra pad nodig, maar moet de antwoorden op dit pad zonder buffering doorgeven:

• nginx: proxy_buffering off en proxy_cache off in het gedeelte voor /rc_wss/,
• Apache: flushpackets=on op de ProxyPass-regel voor /rc_wss/,
• Caddy: flush_interval -1 in de reverse_proxy voor /rc_wss/.

De sjablonen op de accountpagina en in de handleiding voor een eigen domein bevatten deze instellingen al. Als u een oudere configuratie hebt overgenomen, vergelijk die dan met het huidige sjabloon.

Wat in de browser wordt opgeslagen

Na een geslaagde verbinding via HTTPS maakt de widget de vermelding rc_http aan in de sessionStorage van de browser. Deze bevat alleen het tijdstip van die verbinding en geen persoonsgegevens. De widget gebruikt de vermelding zodat volgende pagina’s 30 minuten lang direct de HTTP-fallback gebruiken; zodra WebSocket weer wordt doorgelaten, verwijdert de widget haar. Zoals elke sessionStorage-vermelding verdwijnt ze uiterlijk wanneer het tabblad wordt gesloten. Als sessionStorage niet beschikbaar is, bijvoorbeeld in sommige privévensters, begint elke pagina opnieuw met WebSocket.

Welke route actief is

Open de ontwikkelaarstools van de browser en ga naar het tabblad “Netwerk”:

• WebSocket: er is een verbinding van het type WebSocket naar wss://ws.reactive.chat/rc_wss/ (bij een eigen domein naar uw subdomein).
• HTTP-fallback: er zijn verzoeken naar https://ws.reactive.chat/rc_wss/h/… — eerst h/auf, daarna een langdurig open stream op …/sse (bij long polling herhaalde verzoeken op …/poll) en voor elk verzonden bericht één verzoek op …/tx.

Onder “Applicatie” of “Opslag” kunt u ook zien of de vermelding rc_http bestaat.

Problemen oplossen

De Content Security Policy blokkeert het https-adres

Als connect-src alleen het adres met wss:// vermeldt, blokkeert de browser de fallbackverzoeken. In de browserconsole verschijnt dan een CSP-melding over https://…/rc_wss/h/auf. Waar WebSocket wordt doorgelaten, merkt u niets — maar in netwerken zonder WebSocket komt helemaal geen verbinding tot stand. Voeg het adres met https:// toe zoals hierboven beschreven.

Een proxy buffert de antwoorden

Als een proxy onderweg de stream buffert, komen de Server-Sent Events te laat, in groepen of helemaal niet aan. De widget wacht 5 seconden op het eerste bericht via de stream en schakelt dan over op long polling. De chat werkt daarmee, maar het opbouwen van de verbinding duurt enkele seconden langer. Schakel bij een eigen domein buffering voor /rc_wss/ uit (zie hierboven).

Langdurige verzoeken worden afgebroken

Bij long polling houdt de server een verzoek maximaal 25 seconden open als er niets te melden is. Via een open stream stuurt de server elke 15 seconden een keep-alive-signaal. Firewalls of proxy’s die verzoeken eerder afbreken, dwingen de widget om vaak opnieuw verbinding te maken. Sta toe dat verzoeken naar het chatadres minstens 30 seconden duren.

De chat maakt helemaal geen verbinding

Als zowel WebSocket als de HTTP-fallback mislukt, blijft de widget het op de achtergrond proberen. Controleer of het chatadres vanuit het netwerk van uw bezoekers überhaupt via HTTPS bereikbaar is en of een Content Security Policy of filter het blokkeert.

Verder lezen in de documentatie

Uitgebreid: Transport: WebSocket, HTTP-fallback en opnieuw verbinden. Alle hoofdstukken staan in de documentatie.