Ke halaman utama

Záloha přes HTTP

Když síť blokuje WebSocket, chat automaticky pokračuje přes běžné HTTPS: kdy k tomu dochází, jak to vynutit, co potřebuje vaše Content Security Policy a proxy a jak řešit problémy.

Widget se k chatovacímu serveru běžně připojuje přes WebSocket. Některé sítě to neumožňují. Pro tento případ existuje záloha přes HTTP: chat pak pokračuje přes běžné požadavky HTTPS, aniž byste vy nebo vaši návštěvníci museli cokoli dělat.

Co je záloha přes HTTP

Připojení WebSocket obvykle selhává:

ve firemních sítích, jejichž proxy nebo firewall propouští pouze běžné požadavky HTTP(S),
u poskytovatelů hostingu, CDN nebo nástrojů pro vyvažování zátěže, které nepředávají WebSocket,
za reverzní proxy, která nepředává hlavičky Upgrade a Connection.

Při záloze přes HTTP widget přijímá zprávy serveru jako Server-Sent Events (dlouhodobý stream HTTPS). Pokud tímto streamem nic nepřichází, přepne na long polling. Odesílání používá HTTPS POST. Obě cesty přenášejí stejné zprávy jako WebSocket: návštěvníci píší, dostávají odpovědi asistenta AI i vašich operátorů a několik otevřených karet jako obvykle sdílí jedno připojení. Přílohy se vždy nahrávají přes HTTPS a nezávisí na typu připojení.

Záloha se vztahuje na chatovací widget na vašem webu. Rozhraní vašich operátorů se nadále připojuje přes WebSocket.

Kdy se použije

Widget používá zálohu přes HTTP, když

prohlížeč nepodporuje WebSocket,
dva pokusy o připojení WebSocket selžou za sebou — za neúspěšný se považuje i pokus, který po 8 sekundách není ani navázán, ani odmítnut,
ji vynutíte (viz níže).

K přepnutí dojde pouze tehdy, pokud na stránce dosud nebylo navázáno připojení WebSocket. Pokud již existující připojení WebSocket vypadne, například kvůli změně sítě, widget se znovu připojí přes WebSocket.

Jakmile je záloha aktivní, widget ji na této stránce používá dál. Aby se na dalších stránkách znovu neztrácely dva pokusy, přepnutí si pamatuje: stránky otevřené ve stejné kartě během 30 minut se připojí rovnou přes HTTPS. Současně widget jednou na každé stránce na pozadí ověří, zda už WebSocket projde. Pokud ano, další stránka opět použije WebSocket; aktuální stránka zůstane u zálohy přes HTTP.

Vynucení zálohy

Pro testy nebo prostředí, kde WebSocket prokazatelně nefunguje, můžete zálohu přes HTTP zapnout od začátku. Nejjednodušší je atribut data-rc-transport="http" na značce script widgetu:

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

Widget hledá atribut v celém dokumentu, takže funguje i na jiném prvku, pokud je tento prvek v dokumentu už při spuštění widgetu.

Případně nastavte volbu v JavaScriptu před značkou script widgetu:

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

Pozdější volání ReactiveChat('boot', { transport: 'http' }) na to nemá vliv: typ připojení se určí při spuštění widgetu.

Content Security Policy

Server-Sent Events, long polling a odesílání používají stejnou adresu jako připojení chatu, pouze s https:// místo wss://. Pokud váš web nastavuje Content Security Policy, musí proto connect-src povolit obě podoby:

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

Adresu s https:// používá také offline formulář a nahrávání souborů. U vlastní domény sem patří adresy vaší subdomény:

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

Ostatní položky zásad zůstávají stejné. Co dalšího musí zásady povolovat, popisuje Vložení widgetu.

S vlastní doménou

Pokud chat provozujete přes subdoménu svého webu, záloha přes HTTP používá stejnou cestu /rc_wss/ jako WebSocket. Vaše proxy pro ni nepotřebuje další cestu, ale musí odpovědi na této cestě předávat bez bufferování:

nginx: proxy_buffering off a proxy_cache off v části /rc_wss/,
Apache: flushpackets=on na řádku ProxyPass pro /rc_wss/,
Caddy: flush_interval -1 v reverse_proxy pro /rc_wss/.

Šablony na stránce účtu a v návodu k vlastní doméně už tato nastavení obsahují. Pokud jste převzali starší konfiguraci, porovnejte ji s aktuální šablonou.

Co se ukládá v prohlížeči

Po úspěšném připojení přes HTTPS widget vytvoří v sessionStorage prohlížeče položku rc_http. Obsahuje pouze čas připojení a žádné osobní údaje. Widget ji používá, aby další stránky po dobu 30 minut přešly rovnou na zálohu přes HTTP; jakmile WebSocket znovu projde, položku smaže. Jako každá položka sessionStorage zmizí nejpozději při zavření karty. Pokud sessionStorage není k dispozici, například v některých anonymních oknech, každá stránka opět začíná s WebSocketem.

Která cesta je aktivní

Otevřete vývojářské nástroje prohlížeče a přejděte na kartu „Síť“:

WebSocket: existuje připojení typu WebSocket k wss://ws.reactive.chat/rc_wss/ (s vlastní doménou k vaší subdoméně).
Záloha přes HTTP: existují požadavky na https://ws.reactive.chat/rc_wss/h/… — nejprve h/auf, pak dlouhodobý stream na …/sse (u long pollingu opakované požadavky na …/poll) a jeden požadavek na …/tx pro každou odeslanou zprávu.

V části „Aplikace“ nebo „Úložiště“ také uvidíte, zda je položka rc_http nastavena.

Řešení problémů

Content Security Policy blokuje adresu https

Pokud connect-src uvádí pouze adresu s wss://, prohlížeč požadavky zálohy zablokuje. Konzole prohlížeče pak zobrazuje hlášení CSP k https://…/rc_wss/h/auf. Tam, kde WebSocket projde, si ničeho nevšimnete — v sítích bez WebSocketu ale připojení vůbec nevznikne. Přidejte adresu s https:// podle příkladu výše.

Proxy bufferuje odpovědi

Pokud některá proxy po cestě bufferuje stream, Server-Sent Events přicházejí pozdě, v dávkách nebo vůbec. Widget čeká 5 sekund na první zprávu přes stream a pak přepne na long polling. Chat tak funguje, ale navázání připojení trvá o několik sekund déle. U vlastní domény vypněte bufferování pro /rc_wss/ (viz výše).

Dlouhotrvající požadavky se přerušují

Při long pollingu server drží požadavek otevřený až 25 sekund, pokud nemá co oznámit. Přes otevřený stream odesílá signál keep-alive každých 15 sekund. Firewally nebo proxy, které požadavky ukončují dříve, nutí widget k častému opětovnému připojování. Povolte požadavkům na adresu chatu trvání alespoň 30 sekund.

Chat se vůbec nepřipojí

Pokud selže WebSocket i záloha přes HTTP, widget se dál pokouší připojit na pozadí. Ověřte, zda je adresa chatu ze sítě vašich návštěvníků vůbec dostupná přes HTTPS a zda ji neblokuje Content Security Policy nebo filtr.

Více v dokumentaci

Podrobně: Transport: WebSocket, záloha přes HTTP a opětovné připojení. Všechny kapitoly jsou v dokumentaci.

Kemas kini terakhir: 2026-10-25