HTTP-reserv

Widgeten ansluter normalt till chattservern via WebSocket. Vissa nätverk tillåter inte det. För sådana fall finns HTTP-reserven: chatten fortsätter då via vanliga HTTPS-anrop, utan att du eller dina besökare behöver göra något.

Vad HTTP-reserven är

WebSocket-anslutningar misslyckas ofta:

• i företagsnätverk vars proxy eller brandvägg bara släpper igenom vanliga HTTP(S)-anrop,
• hos webbhotell, CDN:er eller lastbalanserare som inte vidarebefordrar WebSocket,
• bakom en omvänd proxy som inte vidarebefordrar huvudena Upgrade och Connection.

Med HTTP-reserven tar widgeten emot serverns meddelanden som Server-Sent Events (en långlivad HTTPS-ström). Om inget kommer via strömmen byter den till long polling. Meddelanden skickas med HTTPS POST. Båda vägarna bär samma meddelanden som WebSocket: besökarna skriver, får svar från AI-assistenten och dina agenter, och flera öppna flikar delar som vanligt en anslutning. Bilagor laddas ändå upp via HTTPS och beror inte på anslutningstypen.

Reserven gäller chattwidgeten på din webbplats. Agenternas gränssnitt ansluter fortfarande via WebSocket.

När den används

Widgeten använder HTTP-reserven när

• webbläsaren inte stöder WebSocket,
• två WebSocket-anslutningsförsök misslyckas i rad – även ett försök som varken har upprättats eller avvisats efter 8 sekunder räknas som misslyckat,
• du tvingar fram den (se nedan).

Bytet sker bara så länge ingen WebSocket-anslutning har upprättats på sidan. Om en befintlig WebSocket-anslutning bryts, till exempel för att nätverket ändras, återansluter widgeten via WebSocket.

När reserven är aktiv fortsätter widgeten med den på den här sidan. För att efterföljande sidor inte ska förlora två försök igen kommer den ihåg bytet: sidor som öppnas i samma flik inom 30 minuter ansluter direkt via HTTPS. Samtidigt kontrollerar widgeten en gång per sida i bakgrunden om WebSocket nu släpps igenom. Om det fungerar använder nästa sida WebSocket igen; den aktuella sidan fortsätter med HTTP-reserven.

Tvinga fram reserven

För tester eller miljöer där du vet att WebSocket inte fungerar kan du aktivera HTTP-reserven från början. Enklast är attributet data-rc-transport="http" på widgetens skripttagg:

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

Widgeten letar efter attributet i hela dokumentet. Det fungerar därför också på ett annat element, så länge elementet redan finns i dokumentet när widgeten startar.

Du kan i stället ange alternativet i JavaScript, före widgetens skripttagg:

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

Ett senare anrop till ReactiveChat('boot', { transport: 'http' }) påverkar inte detta: anslutningstypen bestäms när widgeten startar.

Content Security Policy

Server-Sent Events, long polling och sändning använder samma adress som chattanslutningen, men med https:// i stället för wss://. Om din webbplats har en Content Security Policy måste connect-src därför tillåta båda formerna:

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

Offlineformuläret och filuppladdningar använder också https:// som adress. Med egen domän anger du adresserna till din underdomän där:

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

Övriga poster i policyn förblir som de är. Vad policyn mer måste tillåta beskrivs i Bädda in widgeten.

Med egen domän

Om du kör chatten via en underdomän till din webbplats använder HTTP-reserven samma sökväg /rc_wss/ som WebSocket. Din proxy behöver ingen ytterligare sökväg för detta, men måste vidarebefordra svaren på sökvägen utan buffring:

• nginx: proxy_buffering off och proxy_cache off i avsnittet /rc_wss/,
• Apache: flushpackets=on på raden ProxyPass för /rc_wss/,
• Caddy: flush_interval -1 i reverse_proxy för /rc_wss/.

Mallarna på kontosidan och i guiden för egen domän innehåller redan dessa inställningar. Om du har tagit över en äldre konfiguration jämför du den med den aktuella mallen.

Vad som lagras i webbläsaren

Efter en lyckad anslutning via HTTPS skapar widgeten posten rc_http i webbläsarens sessionStorage. Den innehåller bara tidpunkten för anslutningen och inga personuppgifter. Widgeten använder den så att efterföljande sidor går direkt till HTTP-reserven i 30 minuter; när WebSocket fungerar igen raderar den posten. Liksom alla poster i sessionStorage försvinner den senast när fliken stängs. Om sessionStorage inte är tillgängligt, till exempel i vissa privata fönster, börjar varje sida med WebSocket igen.

Vilken väg som är aktiv

Öppna webbläsarens utvecklarverktyg och gå till fliken ”Network”:

• WebSocket: det finns en anslutning av typen WebSocket till wss://ws.reactive.chat/rc_wss/ (med egen domän till din underdomän).
• HTTP-reserv: det finns anrop till https://ws.reactive.chat/rc_wss/h/… – först h/auf, sedan en långvarig ström på …/sse (med long polling återkommande anrop till …/poll) och ett anrop till …/tx för varje skickat meddelande.

Under ”Application” eller ”Storage” ser du också om posten rc_http är satt.

Felsökning

Content Security Policy blockerar https-adressen

Om connect-src bara anger wss:// som adress blockerar webbläsaren reservens anrop. Webbläsarkonsolen visar då ett CSP-meddelande om https://…/rc_wss/h/auf. Där WebSocket släpps igenom märker du ingenting – men i nätverk utan WebSocket upprättas ingen anslutning alls. Lägg till https:// som adress enligt ovan.

En proxy buffrar svaren

Om en proxy längs vägen buffrar strömmen kommer Server-Sent Events sent, i omgångar eller inte alls. Widgeten väntar 5 sekunder på det första meddelandet via strömmen och byter sedan till long polling. Chatten fungerar då, men det tar några sekunder längre att upprätta anslutningen. Med egen domän stänger du av buffringen för /rc_wss/ (se ovan).

Långvariga anrop avbryts

Med long polling håller servern ett anrop öppet i upp till 25 sekunder när det inte finns något att rapportera. Via en öppen ström skickar den en keep-alive-signal var 15:e sekund. Brandväggar eller proxyservrar som avbryter anrop tidigare tvingar widgeten att återansluta ofta. Tillåt att anrop till chattadressen varar i minst 30 sekunder.

Chatten ansluter inte alls

Om både WebSocket och HTTP-reserven misslyckas fortsätter widgeten att försöka i bakgrunden. Kontrollera om chattadressen alls går att nå via HTTPS från besökarnas nätverk och om en Content Security Policy eller ett filter blockerar den.

Läs mer i dokumentationen

På djupet: Transport: WebSocket, HTTP-reserv och återanslutning. Alla kapitel finns i dokumentationen.