Tryb awaryjny HTTP

Widżet zwykle łączy się z serwerem czatu przez WebSocket. Niektóre sieci na to nie pozwalają. Na taki przypadek jest tryb awaryjny HTTP: czat działa wtedy dalej przez zwykłe żądania HTTPS, a ani Ty, ani Twoi odwiedzający nie musicie nic robić.

Czym jest tryb awaryjny HTTP

Połączenia WebSocket zwykle nie dochodzą do skutku:

• w sieciach firmowych, których proxy lub firewall przepuszcza tylko zwykłe żądania HTTP(S),
• u hostingodawców, w sieciach CDN lub load balancerach, które nie przekazują WebSocket,
• za reverse proxy, które nie przekazuje nagłówków Upgrade i Connection.

W trybie awaryjnym HTTP widżet odbiera wiadomości serwera jako Server-Sent Events (długo otwarty strumień HTTPS). Jeśli tym strumieniem nic nie dociera, przechodzi na long polling. Wysyłanie odbywa się przez HTTPS POST. Obiema drogami płyną te same wiadomości co przez WebSocket: Twoi odwiedzający piszą, otrzymują odpowiedzi asystenta AI i Twoich agentów, a kilka otwartych kart jak zwykle dzieli jedno połączenie. Załączniki i tak są przesyłane przez HTTPS i nie zależą od rodzaju połączenia.

Tryb awaryjny dotyczy widżetu czatu na Twojej stronie. Interfejs Twoich agentów nadal łączy się przez WebSocket.

Kiedy się włącza

Widżet przechodzi na tryb awaryjny HTTP, gdy

• przeglądarka nie obsługuje WebSocket,
• dwie kolejne próby połączenia przez WebSocket się nie powiodą – za nieudaną uznawana jest też próba, która po 8 sekundach ani nie doszła do skutku, ani nie została odrzucona,
• wymusisz go (patrz niżej).

Zmiana następuje tylko wtedy, gdy na stronie nie doszło jeszcze do żadnego połączenia WebSocket. Jeśli istniejące połączenie WebSocket zostanie przerwane, na przykład przy zmianie sieci, widżet łączy się ponownie przez WebSocket.

Gdy tryb awaryjny jest już aktywny, widżet pozostaje przy nim na tej stronie. Aby kolejne strony nie traciły znowu dwóch prób, zapamiętuje zmianę: strony otwarte w tej samej karcie w ciągu 30 minut łączą się od razu przez HTTPS. Jednocześnie widżet raz na stronę sprawdza w tle, czy WebSocket już przechodzi. Jeśli tak, następna strona znowu używa WebSocket; bieżąca strona zostaje przy trybie awaryjnym HTTP.

Wymuszenie trybu awaryjnego

Do testów lub w środowiskach, w których WebSocket na pewno nie działa, możesz włączyć tryb awaryjny HTTP od początku. Najprościej dodaj atrybut data-rc-transport="http" do tagu script widżetu:

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

Widżet szuka atrybutu w całym dokumencie, więc działa on także przy innym elemencie, o ile ten element jest już w dokumencie w chwili startu widżetu.

Możesz też ustawić opcję w JavaScript, i to przed tagiem script widżetu:

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

Późniejsze wywołanie ReactiveChat('boot', { transport: 'http' }) nie ma na to wpływu: rodzaj połączenia jest ustalany przy starcie widżetu.

Content Security Policy

Server-Sent Events, long polling i wysyłanie korzystają z tego samego adresu co połączenie czatu, tylko z https:// zamiast wss://. Jeśli Twoja strona ustawia Content Security Policy, connect-src musi więc dopuszczać obie formy:

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

Z adresu https:// korzystają też formularz offline i przesyłanie plików. Przy własnej domenie wpisujesz tam adresy swojej subdomeny:

connect-src 'self' wss://chat.twoja-domena.pl https://chat.twoja-domena.pl

Pozostałe wpisy Twojej polityki zostają bez zmian. Co jeszcze polityka musi dopuszczać, opisuje Osadzenie widgetu.

Z własną domeną

Jeśli czat działa przez subdomenę Twojej strony, tryb awaryjny HTTP korzysta z tej samej ścieżki /rc_wss/ co WebSocket. Twoje proxy nie potrzebuje do tego dodatkowej ścieżki, ale musi przekazywać odpowiedzi na tej ścieżce bez buforowania:

• nginx: proxy_buffering off i proxy_cache off w sekcji /rc_wss/,
• Apache: flushpackets=on w linii ProxyPass dla /rc_wss/,
• Caddy: flush_interval -1 w reverse_proxy dla /rc_wss/.

Szablony na stronie konta i w instrukcji Własna domena zawierają już te ustawienia. Jeśli korzystasz ze starszej konfiguracji, porównaj ją z aktualnym szablonem.

Co jest zapisywane w przeglądarce

Po udanym nawiązaniu połączenia przez HTTPS widżet tworzy w sessionStorage przeglądarki wpis rc_http. Zawiera on tylko czas tego połączenia i żadnych danych osobowych. Widżet używa go, aby kolejne strony przez 30 minut od razu korzystały z trybu awaryjnego HTTP; gdy WebSocket znowu przechodzi, usuwa wpis. Jak każdy wpis w sessionStorage znika najpóźniej po zamknięciu karty. Jeśli sessionStorage jest niedostępny, na przykład w niektórych oknach prywatnych, każda strona zaczyna znowu od WebSocket.

Która droga jest aktywna

Otwórz narzędzia deweloperskie przeglądarki i zakładkę „Sieć”:

• WebSocket: jest połączenie typu WebSocket do wss://ws.reactive.chat/rc_wss/ (przy własnej domenie do Twojej subdomeny).
• Tryb awaryjny HTTP: są żądania do https://ws.reactive.chat/rc_wss/h/… – najpierw h/auf, potem długo trwający strumień na …/sse (przy long pollingu powtarzające się żądania na …/poll) i jedno żądanie na …/tx dla każdej wysłanej wiadomości.

W zakładce „Aplikacja” lub „Pamięć” zobaczysz też, czy wpis rc_http jest ustawiony.

Rozwiązywanie problemów

Content Security Policy blokuje adres https

Jeśli w connect-src jest tylko adres wss://, przeglądarka blokuje żądania trybu awaryjnego. W konsoli przeglądarki pojawia się wtedy komunikat CSP dotyczący https://…/rc_wss/h/auf. Tam, gdzie WebSocket przechodzi, nic nie zauważysz – ale w sieciach bez WebSocket połączenie w ogóle nie dojdzie do skutku. Dodaj adres https://, jak pokazano wyżej.

Proxy buforuje odpowiedzi

Jeśli proxy po drodze buforuje strumień, Server-Sent Events docierają z opóźnieniem, partiami albo wcale. Widżet czeka 5 sekund na pierwszą wiadomość w strumieniu, a potem przechodzi na long polling. Czat wtedy działa, ale nawiązanie połączenia trwa kilka sekund dłużej. Przy własnej domenie wyłącz buforowanie dla /rc_wss/ (patrz wyżej).

Długie żądania są przerywane

Przy long pollingu serwer trzyma żądanie otwarte do 25 sekund, gdy nie ma nic do przekazania. Przez otwarty strumień co 15 sekund wysyła sygnał podtrzymujący. Firewalle lub proxy, które przerywają żądania wcześniej, zmuszają widżet do częstego ponownego łączenia. Pozwól, by żądania do adresu czatu trwały co najmniej 30 sekund.

Czat w ogóle się nie łączy

Jeśli zawiodą zarówno WebSocket, jak i tryb awaryjny HTTP, widżet próbuje dalej w tle. Sprawdź, czy adres czatu jest w ogóle osiągalny przez HTTPS z sieci Twoich odwiedzających i czy nie blokuje go Content Security Policy albo filtr.