HTTP-Rückfall

Das Widget verbindet sich normalerweise per WebSocket mit dem Chat-Server. Manche Netze lassen das nicht zu. Für diesen Fall gibt es den HTTP-Rückfall: Der Chat läuft dann über normale HTTPS-Anfragen weiter, ohne dass Sie oder Ihre Besucher etwas tun müssen.

Was der HTTP-Rückfall ist

WebSocket-Verbindungen scheitern typischerweise:

• in Firmennetzen, deren Proxy oder Firewall nur gewöhnliche HTTP(S)-Anfragen durchlässt,
• bei Hostern, CDNs oder Load-Balancern, die keine WebSockets weiterleiten,
• hinter einem Reverse-Proxy, der die Kopfzeilen Upgrade und Connection nicht weiterreicht.

Im HTTP-Rückfall empfängt das Widget die Nachrichten des Servers als Server-Sent Events (ein lang offener HTTPS-Datenstrom). Kommt über diesen Strom nichts an, wechselt es auf Long-Polling. Gesendet wird per HTTPS-POST. Über beide Wege laufen dieselben Nachrichten wie über den WebSocket: Ihre Besucher schreiben, bekommen die Antworten des KI-Assistenten und Ihrer Agenten, und mehrere offene Tabs teilen sich wie gewohnt eine Verbindung. Datei-Anhänge werden ohnehin per HTTPS hochgeladen und sind vom Verbindungsweg unabhängig.

Der Rückfall betrifft das Chat-Widget auf Ihrer Website. Die Oberfläche Ihrer Agenten verbindet sich weiterhin per WebSocket.

Wann er greift

Das Widget nimmt den HTTP-Rückfall, wenn

• der Browser keine WebSockets kennt,
• zwei Verbindungsversuche per WebSocket nacheinander scheitern – als gescheitert gilt auch ein Versuch, der nach 8 Sekunden weder zustande gekommen noch abgewiesen worden ist,
• Sie ihn erzwingen (siehe unten).

Der Wechsel geschieht nur, solange auf der Seite noch keine WebSocket-Verbindung zustande gekommen ist. Bricht eine bestehende WebSocket-Verbindung ab, etwa durch einen Netzwechsel, verbindet sich das Widget wieder per WebSocket.

Ist der Rückfall einmal aktiv, bleibt das Widget für diese Seite dabei. Damit Folgeseiten nicht erneut zwei Versuche verlieren, merkt es sich den Wechsel: Seiten, die innerhalb von 30 Minuten im selben Tab geöffnet werden, verbinden sich direkt über HTTPS. Gleichzeitig prüft das Widget einmal je Seite im Hintergrund, ob ein WebSocket inzwischen durchkommt. Gelingt das, nimmt die nächste Seite wieder den WebSocket; die laufende Seite bleibt beim HTTP-Rückfall.

Den Rückfall erzwingen

Für Tests oder für Umgebungen, in denen WebSockets bekanntermaßen nicht funktionieren, können Sie den HTTP-Rückfall von Anfang an einschalten. Am einfachsten setzen Sie das Attribut data-rc-transport="http" an das Skript-Tag des Widgets:

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

Das Widget sucht das Attribut im ganzen Dokument; es wirkt also auch an einem anderen Element, solange es beim Start des Widgets bereits im Dokument steht.

Alternativ setzen Sie die Einstellung per JavaScript, und zwar vor dem Skript-Tag des Widgets:

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

Ein späterer Aufruf von ReactiveChat('boot', { transport: 'http' }) wirkt dafür nicht: Die Verbindungsart steht beim Start des Widgets fest.

Content-Security-Policy

Server-Sent Events, Long-Polling und das Senden laufen über dieselbe Adresse wie die Chat-Verbindung, nur mit https:// statt wss://. Setzt Ihre Website eine Content-Security-Policy, muss connect-src deshalb beide Formen erlauben:

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

Über die https://-Adresse laufen außerdem das Offline-Formular und die Datei-Uploads. Mit eigener Domain stehen dort die Adressen Ihrer Subdomain:

connect-src 'self' wss://chat.ihre-domain.de https://chat.ihre-domain.de

Weitere Angaben Ihrer Richtlinie bleiben, wie sie sind. Was die Richtlinie sonst erlauben muss, steht unter Das Widget einbinden.

Mit eigener Domain

Betreiben Sie den Chat über eine Subdomain Ihrer Website, läuft der HTTP-Rückfall über denselben Pfad /rc_wss/ wie der WebSocket. Ihr Proxy braucht dafür keinen weiteren Pfad, muss die Antworten auf diesem Pfad aber ungepuffert weiterreichen:

• nginx: proxy_buffering off und proxy_cache off im Abschnitt für /rc_wss/,
• Apache: flushpackets=on an der ProxyPass-Zeile für /rc_wss/,
• Caddy: flush_interval -1 im reverse_proxy für /rc_wss/.

Die Vorlagen auf der Kontoseite und in der Anleitung Eigene Domain enthalten diese Einstellungen bereits. Wenn Sie eine ältere Konfiguration übernommen haben, vergleichen Sie sie mit der aktuellen Vorlage.

Was im Browser gespeichert wird

Nach einem erfolgreichen Verbindungsaufbau über HTTPS legt das Widget im sessionStorage des Browsers den Eintrag rc_http an. Er enthält nur den Zeitpunkt dieses Aufbaus und keine personenbezogenen Daten. Das Widget nutzt ihn, damit Folgeseiten 30 Minuten lang direkt den HTTP-Rückfall nehmen; kommt der WebSocket wieder durch, löscht es den Eintrag. Wie jeder sessionStorage-Eintrag verschwindet er spätestens, wenn der Tab geschlossen wird. Ist der sessionStorage nicht verfügbar, etwa in manchen privaten Fenstern, beginnt jede Seite wieder mit dem WebSocket.

Welcher Weg aktiv ist

Öffnen Sie die Entwicklerwerkzeuge des Browsers und dort den Reiter „Netzwerk“:

• WebSocket: Es gibt eine Verbindung vom Typ WebSocket zu wss://ws.reactive.chat/rc_wss/ (mit eigener Domain zu Ihrer Subdomain).
• HTTP-Rückfall: Es gibt Anfragen an https://ws.reactive.chat/rc_wss/h/… – zuerst h/auf, danach einen lang laufenden Datenstrom auf …/sse (bei Long-Polling wiederkehrende Anfragen auf …/poll) und für jede gesendete Nachricht eine Anfrage auf …/tx.

Unter „Anwendung“ bzw. „Speicher“ sehen Sie außerdem, ob der Eintrag rc_http gesetzt ist.

Fehlerbehebung

Die Content-Security-Policy blockiert die https-Adresse

Steht in connect-src nur die wss://-Adresse, blockiert der Browser die Anfragen des Rückfalls. In der Browserkonsole erscheint dann eine CSP-Meldung zu https://…/rc_wss/h/auf. Wo der WebSocket durchkommt, merken Sie davon nichts – in Netzen ohne WebSocket kommt dann aber gar keine Verbindung zustande. Ergänzen Sie die https://-Adresse wie oben gezeigt.

Ein Proxy puffert die Antworten

Puffert ein Proxy auf dem Weg den Datenstrom, kommen die Server-Sent Events nicht oder nur gesammelt an. Das Widget wartet 5 Sekunden auf die erste Nachricht über den Strom und wechselt dann auf Long-Polling. Der Chat funktioniert damit, der Verbindungsaufbau dauert aber einige Sekunden länger. Mit eigener Domain schalten Sie die Pufferung für /rc_wss/ ab (siehe oben).

Lang laufende Anfragen werden gekappt

Beim Long-Polling hält der Server eine Anfrage bis zu 25 Sekunden offen, wenn es nichts zu melden gibt. Über einen offenen Datenstrom schickt er alle 15 Sekunden ein Lebenszeichen. Firewalls oder Proxys, die Anfragen schon vorher abbrechen, zwingen das Widget zu häufigen Neuverbindungen. Erlauben Sie für die Chat-Adresse Anfragen von mindestens 30 Sekunden Dauer.

Der Chat verbindet sich gar nicht

Scheitern WebSocket und HTTP-Rückfall, versucht das Widget es im Hintergrund weiter. Prüfen Sie dann, ob die Chat-Adresse aus dem Netz Ihrer Besucher per HTTPS überhaupt erreichbar ist und ob eine Content-Security-Policy oder ein Filter sie sperrt.