Fallback HTTP

Il widget normalmente si collega al server della chat tramite WebSocket. Alcune reti non lo consentono. Per questi casi esiste il fallback HTTP: la chat prosegue tramite normali richieste HTTPS, senza che Lei o i Suoi visitatori dobbiate fare nulla.

Che cos’è il fallback HTTP

Le connessioni WebSocket in genere non riescono:

• nelle reti aziendali in cui il proxy o il firewall lascia passare solo normali richieste HTTP(S),
• con provider di hosting, CDN o bilanciatori di carico che non inoltrano i WebSocket,
• dietro un proxy inverso che non trasmette le intestazioni Upgrade e Connection.

Nel fallback HTTP il widget riceve i messaggi del server come Server-Sent Events (un flusso HTTPS di lunga durata). Se da questo flusso non arriva nulla, passa al long polling. L’invio usa HTTPS POST. Entrambe le modalità trasportano gli stessi messaggi del WebSocket: i visitatori scrivono, ricevono le risposte dell’assistente IA e degli operatori e più schede aperte condividono una connessione come di consueto. Gli allegati vengono comunque caricati tramite HTTPS e non dipendono dal tipo di connessione.

Il fallback riguarda il widget di chat sul Suo sito. L’interfaccia degli operatori continua a collegarsi tramite WebSocket.

Quando si attiva

Il widget usa il fallback HTTP quando

• il browser non supporta i WebSocket,
• due tentativi consecutivi di connessione WebSocket falliscono; è considerato fallito anche un tentativo che dopo 8 secondi non è stato né completato né rifiutato,
• Lei lo forza (vedere sotto).

Il passaggio avviene solo finché sulla pagina non è stata stabilita alcuna connessione WebSocket. Se una connessione WebSocket esistente si interrompe, ad esempio perché cambia la rete, il widget si ricollega tramite WebSocket.

Una volta attivo, il widget mantiene il fallback per questa pagina. Per evitare che anche le pagine successive perdano due tentativi, ricorda il passaggio: le pagine aperte nella stessa scheda entro 30 minuti si collegano direttamente tramite HTTPS. Nel frattempo, una volta per pagina, il widget verifica in background se ora un WebSocket riesce a passare. Se ci riesce, la pagina successiva torna a usare WebSocket; quella attuale resta sul fallback HTTP.

Forzare il fallback

Per i test o negli ambienti in cui è noto che i WebSocket non funzionano, può attivare il fallback HTTP fin dall’inizio. Il modo più semplice è l’attributo data-rc-transport="http" sul tag script del widget:

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

Il widget cerca l’attributo nell’intero documento, quindi funziona anche su un altro elemento, purché questo sia già presente nel documento all’avvio del widget.

In alternativa, imposti l’opzione in JavaScript, prima del tag script del widget:

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

Una chiamata successiva a ReactiveChat('boot', { transport: 'http' }) non ha effetto: il tipo di connessione viene fissato all’avvio del widget.

Content Security Policy

Server-Sent Events, long polling e invio usano lo stesso indirizzo della connessione della chat, ma con https:// al posto di wss://. Se il Suo sito imposta una Content Security Policy, connect-src deve quindi consentire entrambe le forme:

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

Anche il modulo offline e il caricamento di file usano l’indirizzo https:// per le richieste. Con un dominio personalizzato vanno inseriti gli indirizzi del Suo sottodominio:

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

Le altre voci della policy restano invariate. Gli altri elementi che la policy deve consentire sono descritti in Incorporare il widget.

Con un dominio personalizzato

Se fa passare la chat attraverso un sottodominio del Suo sito, il fallback HTTP usa lo stesso percorso /rc_wss/ del WebSocket. Il proxy non necessita di un percorso aggiuntivo, ma deve trasmettere le risposte su questo percorso senza buffering:

• nginx: proxy_buffering off e proxy_cache off nella sezione /rc_wss/,
• Apache: flushpackets=on sulla riga ProxyPass per /rc_wss/,
• Caddy: flush_interval -1 nel reverse_proxy per /rc_wss/.

I modelli nella pagina dell’account e nella guida al dominio personalizzato contengono già queste impostazioni. Se ha adottato una configurazione precedente, la confronti con il modello attuale.

Che cosa viene memorizzato nel browser

Dopo una connessione HTTPS riuscita, il widget crea la voce rc_http nel sessionStorage del browser. Contiene solo l’ora della connessione, senza dati personali. Il widget la usa affinché le pagine successive passino direttamente al fallback HTTP per 30 minuti; appena il WebSocket riesce di nuovo a passare, elimina la voce. Come ogni voce di sessionStorage, scompare al più tardi alla chiusura della scheda. Se sessionStorage non è disponibile, ad esempio in alcune finestre private, ogni pagina ricomincia dal WebSocket.

Quale modalità è attiva

Apra gli strumenti per sviluppatori del browser e vada nella scheda «Rete»:

• WebSocket: è presente una connessione di tipo WebSocket a wss://ws.reactive.chat/rc_wss/ (con un dominio personalizzato, al Suo sottodominio).
• Fallback HTTP: sono presenti richieste a https://ws.reactive.chat/rc_wss/h/… — prima h/auf, poi un flusso di lunga durata su …/sse (con il long polling, richieste ricorrenti su …/poll) e una richiesta su …/tx per ogni messaggio inviato.

In «Applicazione» o «Archiviazione» può anche vedere se è impostata la voce rc_http.

Risoluzione dei problemi

La Content Security Policy blocca l’indirizzo https

Se connect-src elenca solo l’indirizzo wss://, il browser blocca le richieste del fallback. La console mostra allora un messaggio CSP relativo a https://…/rc_wss/h/auf. Dove il WebSocket riesce a passare non noterà nulla, ma nelle reti senza WebSocket non viene stabilita alcuna connessione. Aggiunga l’indirizzo https:// come mostrato sopra.

Un proxy memorizza le risposte nel buffer

Se un proxy lungo il percorso memorizza il flusso nel buffer, i Server-Sent Events arrivano in ritardo, a gruppi oppure non arrivano affatto. Il widget attende 5 secondi il primo messaggio sul flusso e poi passa al long polling. La chat funziona comunque, ma la connessione richiede qualche secondo in più. Con un dominio personalizzato, disattivi il buffering per /rc_wss/ (vedere sopra).

Le richieste di lunga durata vengono interrotte

Con il long polling, il server tiene aperta una richiesta fino a 25 secondi quando non ha nulla da comunicare. Su un flusso aperto invia un segnale di mantenimento della connessione ogni 15 secondi. Firewall o proxy che interrompono prima le richieste costringono il widget a ricollegarsi spesso. Consenta alle richieste verso l’indirizzo della chat di durare almeno 30 secondi.

La chat non si collega affatto

Se falliscono sia il WebSocket sia il fallback HTTP, il widget continua a riprovare in background. Verifichi se l’indirizzo della chat è raggiungibile tramite HTTPS dalla rete dei visitatori e se una Content Security Policy o un filtro lo blocca.

Approfondimenti nella documentazione

In dettaglio: Trasporto: WebSocket, fallback HTTP e riconnessione. Tutti i capitoli sono nella documentazione.