Fallback HTTP

Normalmente, o widget se conecta ao servidor do chat por WebSocket. Algumas redes não permitem isso. Para esse caso existe o fallback HTTP: o chat continua por requisições HTTPS comuns, sem que você ou seus visitantes precisem fazer nada.

O que é o fallback HTTP

Conexões WebSocket costumam falhar:

• em redes corporativas cujo proxy ou firewall só permite requisições HTTP(S) comuns,
• com provedores de hospedagem, CDNs ou balanceadores de carga que não encaminham WebSockets,
• atrás de um proxy reverso que não repassa os cabeçalhos Upgrade e Connection.

No fallback HTTP, o widget recebe as mensagens do servidor como Server-Sent Events (um fluxo HTTPS de longa duração). Se nada chegar por esse fluxo, ele muda para long polling. O envio usa HTTPS POST. As duas formas transportam as mesmas mensagens que o WebSocket: seus visitantes escrevem, recebem as respostas do assistente de IA e dos atendentes, e várias abas abertas compartilham uma conexão, como de costume. Os anexos já são enviados por HTTPS e não dependem do tipo de conexão.

O fallback se aplica ao widget de chat do seu site. A interface dos atendentes continua se conectando por WebSocket.

Quando ele é usado

O widget usa o fallback HTTP quando

• o navegador não oferece suporte a WebSockets,
• duas tentativas consecutivas de conexão WebSocket falham; uma tentativa que não foi estabelecida nem rejeitada após 8 segundos também conta como falha,
• você o força (veja abaixo).

A mudança só acontece enquanto nenhuma conexão WebSocket tiver sido estabelecida na página. Se uma conexão WebSocket existente cair, por exemplo por uma mudança de rede, o widget se reconecta por WebSocket.

Depois que o fallback é ativado, o widget o mantém nessa página. Para que as páginas seguintes não percam outras duas tentativas, ele lembra a mudança: páginas abertas na mesma aba dentro de 30 minutos se conectam diretamente por HTTPS. Ao mesmo tempo, o widget verifica em segundo plano, uma vez por página, se agora é possível estabelecer um WebSocket. Se for, a próxima página volta a usar WebSocket; a página atual continua no fallback HTTP.

Forçar o fallback

Para testes ou ambientes em que se sabe que WebSockets não funcionam, você pode ativar o fallback HTTP desde o início. A forma mais simples é usar o atributo data-rc-transport="http" na tag script do widget:

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

O widget procura o atributo no documento inteiro; por isso ele também funciona em outro elemento, desde que esse elemento já esteja no documento quando o widget iniciar.

Como alternativa, defina a opção em JavaScript, antes da tag script do widget:

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

Uma chamada posterior de ReactiveChat('boot', { transport: 'http' }) não tem efeito nesse caso: o tipo de conexão é definido quando o widget inicia.

Content Security Policy

Server-Sent Events, long polling e envio usam o mesmo endereço da conexão do chat, mas com https:// no lugar de wss://. Se o seu site define uma Content Security Policy, connect-src precisa permitir as duas formas:

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

O formulário offline e o envio de arquivos também usam o endereço https:// para isso. Com um domínio próprio, entram ali os endereços do seu subdomínio:

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

As outras entradas da sua política permanecem como estão. O que mais a política precisa permitir está descrito em Incorporar o widget.

Com domínio próprio

Se você executa o chat por um subdomínio do seu site, o fallback HTTP usa o mesmo caminho /rc_wss/ do WebSocket. Seu proxy não precisa de um caminho adicional, mas deve repassar as respostas nesse caminho sem buffering:

• nginx: proxy_buffering off e proxy_cache off na seção /rc_wss/,
• Apache: flushpackets=on na linha ProxyPass de /rc_wss/,
• Caddy: flush_interval -1 no reverse_proxy de /rc_wss/.

Os modelos na página da conta e no guia de domínio próprio já contêm essas configurações. Se você adotou uma configuração mais antiga, compare-a com o modelo atual.

O que é armazenado no navegador

Após uma conexão bem-sucedida por HTTPS, o widget cria a entrada rc_http no sessionStorage do navegador. Ela contém apenas o horário dessa conexão, sem dados pessoais. O widget a usa para que as páginas seguintes passem diretamente ao fallback HTTP durante 30 minutos; assim que o WebSocket volta a passar, ele exclui a entrada. Como qualquer entrada de sessionStorage, ela desaparece, no máximo, quando a aba é fechada. Se o sessionStorage não estiver disponível, por exemplo em algumas janelas privadas, cada página começa novamente pelo WebSocket.

Qual forma de conexão está ativa

Abra as ferramentas de desenvolvedor do navegador e acesse a aba “Rede”:

• WebSocket: há uma conexão do tipo WebSocket com wss://ws.reactive.chat/rc_wss/ (com domínio próprio, com o seu subdomínio).
• Fallback HTTP: há requisições para https://ws.reactive.chat/rc_wss/h/… — primeiro h/auf, depois um fluxo de longa duração em …/sse (com long polling, requisições recorrentes em …/poll) e uma requisição em …/tx para cada mensagem enviada.

Em “Aplicativo” ou “Armazenamento”, você também pode ver se a entrada rc_http está definida.

Solução de problemas

A Content Security Policy bloqueia o endereço https

Se connect-src lista apenas o endereço wss://, o navegador bloqueia as requisições do fallback. O console mostra então uma mensagem da CSP sobre https://…/rc_wss/h/auf. Onde o WebSocket passa, você não percebe nada, mas em redes sem WebSocket nenhuma conexão é estabelecida. Adicione o endereço https:// como mostrado acima.

Um proxy armazena as respostas em buffer

Se um proxy no caminho armazena o fluxo em buffer, os Server-Sent Events chegam com atraso, em lotes ou não chegam. O widget espera 5 segundos pela primeira mensagem do fluxo e depois muda para long polling. O chat funciona assim, mas estabelecer a conexão leva alguns segundos a mais. Com domínio próprio, desative o buffering de /rc_wss/ (veja acima).

Requisições de longa duração são interrompidas

Com long polling, o servidor mantém uma requisição aberta por até 25 segundos quando não há nada a informar. Em um fluxo aberto, envia um sinal de manutenção da conexão a cada 15 segundos. Firewalls ou proxies que interrompem as requisições antes disso obrigam o widget a se reconectar com frequência. Permita que as requisições ao endereço do chat durem pelo menos 30 segundos.

O chat não se conecta de forma alguma

Se tanto o WebSocket quanto o fallback HTTP falharem, o widget continua tentando em segundo plano. Verifique se o endereço do chat pode ser acessado por HTTPS a partir da rede dos seus visitantes e se uma Content Security Policy ou um filtro o bloqueia.

Saiba mais na documentação

Em detalhes: Transporte: WebSocket, fallback HTTP e reconexão. Todos os capítulos estão na documentação.