Perché la pagina del tuo sito resta aperta dopo la richiesta

Se la pagina deve ricevere un avviso più tardi, o mostrare la modifica di un'altra persona, la domanda è se basta una richiesta. Il 3 novembre 2026 ho letto il documento RFC 6455, due pagine di nginx, la guida MDN e la pagina pubblica su HTTP/3. Non dicono la stessa cosa. Non ho misurato un sito e non ho aperto un canale.

Il documento del dicembre 2011

RFC 6455, The WebSocket Protocol, è di I. Fette, Google, e A. Melnikov, Isode. È sul percorso degli standard. La data del documento è dicembre 2011. Il copyright è 2011, IETF Trust. La risposta letta il 3 novembre 2026 alle 04:59:11 GMT non ha last-modified. Non invento una data di revisione.

L'abstract dice che il protocollo permette la comunicazione nei due sensi fra un client, che esegue codice non fidato in un ambiente controllato, e un host remoto che ha accettato di parlare con quel codice. Il modello di sicurezza è quello dell'origine, lo stesso dei browser. Il protocollo è una stretta di mano di apertura e poi un framing di messaggi, sopra TCP. L'obiettivo è un meccanismo, per applicazioni nel browser che hanno bisogno dei due sensi, che non dipenda dall'aprire più connessioni HTTP.

La sezione 1.1 è marcata non normativa. Dice che le applicazioni con bisogno dei due sensi, e fa gli esempi della messaggistica istantanea e dei giochi, hanno usato HTTP per interrogare il server, mentre gli avvisi verso il server viaggiavano su chiamate distinte. Elenca tre problemi. Il server usa più connessioni TCP per ogni client: una per mandare informazioni al client e una nuova per ogni messaggio in arrivo. Ogni messaggio dal client al server porta un'intestazione HTTP. Lo script sul client deve tenere la mappa fra le connessioni in uscita e la connessione in entrata, per seguire le risposte. Una soluzione più semplice, scrive, è una sola connessione TCP per il traffico nei due sensi. È quello che il protocollo fornisce. Insieme alla WebSocket API è un'alternativa all'interrogazione HTTP, per i due sensi da una pagina verso un server remoto.

La stessa sezione elenca altri usi: giochi, quotazioni, applicazioni con più persone che modificano insieme, interfacce che espongono in tempo reale servizi del server. Non sono misure. Sono l'elenco del documento. Più avanti dice che il protocollo è pensato per sostituire tecnologie bidirezionali che usano HTTP come trasporto, così da riusare l'infrastruttura già presente: proxy, filtri, autenticazione. Quelle tecnologie, scrive, erano un compromesso fra efficienza e affidabilità, perché HTTP all'inizio non era pensato per i due sensi. Il protocollo prova a riprenderne gli obiettivi dentro l'infrastruttura HTTP esistente. È disegnato per le porte 80 e 443 e per i proxy e gli intermediari HTTP, anche se questo comporta complessità. Il disegno non limita il protocollo a HTTP: implementazioni future potrebbero usare una stretta di mano più semplice su una porta dedicata. I modelli di traffico della messaggistica interattiva non somigliano al traffico HTTP ordinario e possono caricare in modo inusuale alcuni componenti. Non dice quali. Non ne invento.

L'elenco dell'infrastruttura, in questa sezione, non è ancora la frase su come si autentica un client. Non le unisco.

Dopo la stretta di mano

La sezione 1.2, non normativa, divide il protocollo in due parti: la stretta di mano e il trasferimento. La riga iniziale del client segue il formato della riga di richiesta. La riga iniziale del server segue il formato della riga di stato. Dopo, un insieme di campi. Possono esserci campi ulteriori, fra cui i cookie. Se la stretta di mano è riuscita, parte il trasferimento: un canale nei due sensi in cui ciascun lato può, indipendentemente dall'altro, mandare dati quando vuole. I dati viaggiano in messaggi. Sul cavo un messaggio è uno o più frame. Un messaggio frammentato può essere riunito o spezzato da un intermediario. I tipi sono testo, binario e frame di controllo, questi ultimi per il protocollo, per esempio per dire che la connessione va chiusa. I cookie di questa frase sono campi possibili nella stretta di mano. Non sono ancora la frase sull'autenticazione.

La sezione 1.3, non normativa, dice che la stretta di mano di apertura è pensata per essere compatibile con il software lato server basato su HTTP e con gli intermediari, così una sola porta serve sia i client HTTP sia i client di questo protocollo. La stretta di mano del client è una richiesta HTTP di Upgrade.

La sezione 1.7, non normativa, dice che il protocollo è indipendente e basato su TCP. L'unico rapporto con HTTP è che la stretta di mano viene letta dai server HTTP come una richiesta di Upgrade. Di default la porta è 80 per le connessioni ordinarie, e 443 per le connessioni in tunnel TLS. La sezione 10.6, più avanti e normativa, dice un'altra cosa: riservatezza e integrità si ottengono eseguendo il protocollo sopra TLS, con gli URI di schema wss. Le implementazioni devono supportare TLS e dovrebbero usarlo. Le due sezioni stanno nello stesso documento del dicembre 2011. La porta 443 e lo schema wss non sono la stessa frase. Non le unisco.

La sezione 1.8, non normativa, parla della porta condivisa con un server HTTP, caso probabile sulle porte 80 e 443. A quel server la connessione appare come una richiesta ordinaria con un'offerta di Upgrade. In un impianto semplice, un indirizzo e un solo server per quel nome, questo può bastare a mettere in esercizio il protocollo. In impianti più complessi, per esempio bilanciatori e più server, il documento dice che è probabilmente più facile un insieme di host dedicati, separati dai server HTTP. Al momento della scrittura, aggiunge, le connessioni sulla porta 80 e sulla porta 443 avevano tassi di successo molto diversi, e la 443 riusciva molto più spesso. Può cambiare nel tempo. È una nota del dicembre 2011. Non è una misura del 3 novembre 2026. Non è il tempo di nginx.

Chi chiude, e il riavvio

La sezione 1.4, non normativa, descrive la chiusura. Ciascuno dei due lati può mandare un frame di controllo per cominciarla. L'altro risponde con un frame di chiusura, se non ne ha già mandato uno. Poi il primo chiude, sapendo che non arriveranno altri dati. Dopo aver mandato quel frame non si mandano altri dati. Dopo averlo ricevuto si scartano i dati ulteriori. I due lati possono cominciarla insieme. La chiusura del protocollo completa la chiusura TCP, perché quella non è sempre affidabile da un capo all'altro, soprattutto se ci sono proxy che intercettano.

La sezione 7.3 è normativa. I server possono chiudere la connessione quando vogliono. I client non dovrebbero chiuderla in modo arbitrario. In entrambi i casi si comincia con la procedura di chiusura.

Il codice 1001, sezione 7.4.1, indica che un estremo se ne sta andando, per esempio un server che si spegne o un browser che ha lasciato la pagina. Il codice 1000 è un'altra frase: chiusura normale, lo scopo per cui la connessione era stata aperta è compiuto. Non li unisco. Il 1001 è il modo in cui questo documento nomina lo spegnimento e l'uscita dalla pagina. Non è un tempo in secondi.

La sezione 7.2.1 dice che, se la connessione di trasporto si perde in modo inatteso, il client deve considerare fallita la connessione di questo protocollo. Non è il codice 1001. Una è la perdita del trasporto. L'altra è l'estremo che se ne va. Non le unisco.

La sezione 7.2.3 dice che una chiusura anomala può essere un errore passeggero: riconnettersi può ridare una connessione buona. Può anche essere un problema che non passa. Se ogni client, dopo la chiusura anomala, riprova subito e di continuo, il servizio può non riprendersi in tempo, o la ripresa diventa molto più difficile. Per questo i client dovrebbero attendere prima di riprovare. Il primo tentativo dovrebbe essere ritardato di un tempo casuale. I parametri li sceglie il client. Un valore a caso fra 0 e 5 secondi è, per il documento, un ritardo iniziale ragionevole, ma il client può scegliere un altro intervallo. Se il primo tentativo fallisce, i successivi dovrebbero attendere di più, con un metodo come il backoff esponenziale binario troncato. Lo 0 e il 5 sono l'esempio del dicembre 2011. Non sono un tempo che ho misurato. Non sono i 60 secondi di nginx.

Autenticazione, nello stesso documento

La sezione 10.5 dice che il protocollo non prescrive un modo particolare per autenticare i client durante la stretta di mano. Il server può usare qualunque meccanismo di autenticazione del client disponibile a un server HTTP generico, come i cookie, l'autenticazione HTTP o l'autenticazione TLS. La sezione non descrive i passi.

La sezione 10.2 dice che i server destinati solo ad alcuni siti, e non a qualunque pagina, dovrebbero verificare che il campo Origin sia un'origine attesa. Se l'origine non è accettabile, dovrebbero rispondere alla stretta di mano con lo stato 403. Non descrivo altro di quella sezione.

I cookie della sezione 1.2 sono campi che possono esserci. I cookie della sezione 10.5 sono un esempio di meccanismo che un server HTTP generico già ha. Non sono la stessa frase. L'elenco proxy, filtri, autenticazione della sezione 1.1 è il disegno. Il 403 è un consiglio della sezione 10.2. Non li unisco.

La pagina nginx del 22 ottobre 2026

La pagina WebSocket proxying ha last-modified 22 ottobre 2026 alle 11:23:19 GMT. La risposta letta il 3 novembre 2026 porta la data 04:59:21 GMT. Le due date non coincidono. Non le unisco. Indirizzo: https://nginx.org/en/docs/http/websocket.html.

Dice che per trasformare una connessione fra client e server da HTTP 1.1 in WebSocket si usa il passaggio di protocollo di HTTP 1.1. Upgrade è un'intestazione che vale solo per quel salto, e non viene passata dal client al server proxato. Con un proxy inverso il client non vede il proxy, quindi il trattamento speciale sta sul proxy. Dalla versione 1.3.13 nginx apre un tunnel fra client e server proxato se quel server risponde con il codice 101 e il client ha chiesto il passaggio tramite Upgrade. Le intestazioni di quel salto, Upgrade e Connection, non passano da sole: la pagina dice che vanno passate in modo esplicito. Nell'esempio annota che impostare la versione 1.1 verso il proxy serviva prima della versione 1.29.7. È una nota della pagina. Non è una misura mia.

Di default, scrive, la connessione viene chiusa se il server proxato non trasmette alcun dato entro 60 secondi. Quel tempo si può aumentare con la direttiva proxy_read_timeout. In alternativa il server proxato può mandare periodicamente frame di ping, per azzerare il tempo e controllare se la connessione è ancora viva. Il 60 di questa pagina non è lo 0 e il 5 del dicembre 2011. Non è il codice 1001. Non li unisco.

Il modulo proxy, stesso secondo di modifica

Il modulo ngx_http_proxy_module ha last-modified 22 ottobre 2026 alle 11:23:19 GMT, lo stesso secondo della pagina sul canale. La risposta letta il 3 novembre 2026 porta la data 05:02:05 GMT, non le 04:59:21 GMT dell'altra pagina. Stesso secondo di modifica, due letture. Non le unisco in un solo orario. Indirizzo: https://nginx.org/en/docs/http/ngx_http_proxy_module.html.

proxy_read_timeout ha predefinito 60 secondi. Vale nel contesto http, server e location. È il tempo per leggere una risposta dal server proxato. Il tempo è solo fra due operazioni di lettura successive, non per la trasmissione dell'intera risposta. Se in quel tempo il server proxato non trasmette nulla, la connessione si chiude.

La pagina sul canale dice entro 60 secondi e rimanda a questa direttiva. Il modulo dice che quei secondi stanno fra due letture, non sull'intera risposta. Sono due frasi. Non le unisco in un canale che durerebbe 60 secondi.

La pagina sul lavoro lungo cita questo modulo per un'altra domanda: che cosa togliere da una richiesta, non un canale che resta aperto. Non la riscrivo. Perché la pagina del tuo sito aspetta un lavoro lungo.

La guida MDN, altro 22 ottobre

La guida WebSocket API ha in pagina l'ultima modifica il 22 ottobre 2026, senza un'ora. Last-modified della risposta: 3 novembre 2026 alle 00:53:07 GMT. Il 22 ottobre e il 3 novembre non coincidono. Non li unisco. Il 22 ottobre di questa guida non è le 11:23:19 GMT di nginx: qui l'ora non c'è. Non la invento. Indirizzo: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API.

Dice che l'API permette di aprire una sessione interattiva nei due sensi fra il browser della persona e un server. Si possono mandare messaggi e ricevere risposte senza interrogare il server per una risposta. È la stessa idea dell'alternativa all'interrogazione nel documento del 2011. Le date restano due. Non le unisco.

La stessa guida dice che l'interfaccia non ha contropressione. Se i messaggi arrivano più in fretta di quanto l'applicazione li elabori, la pagina può riempire la memoria del dispositivo, diventare non responsiva per l'uso del processore, o tutte e due le cose. Se il problema è la contropressione, la guida indica l'API WebTransport. Non l'ho aperta. Non assegno a questo limite i 60 secondi di nginx, né lo 0 e il 5 del 2011.

Una nota della stessa guida: se una pagina ha una connessione WebSocket aperta, il browser può non metterla nella bfcache. Conviene chiudere la connessione quando la persona ha finito con la pagina. La pagina già online su quel ritorno indietro è un altro argomento. Non la riscrivo. Perché tornando indietro il tuo sito mostra la pagina com'era.

La guida non scrive il codice 1001, non scrive lo stato 403, non scrive 60 secondi, non elenca i cookie. Non glieli assegno.

La pagina su HTTP/3

Letta il 3 novembre 2026: HTTP/3: come funziona e quando può migliorare le prestazioni. Data di pubblicazione 3 ottobre 2026, aggiornata il 2 novembre 2026. Parla del trasporto delle richieste, HTTP su QUIC sopra UDP, e di quando un pacchetto perso resta su una richiesta. Non parla di un canale che resta aperto dopo la stretta di mano. Nel controllo del testo non compaiono il nome WebSocket, una connessione lunga, un avviso, né il passaggio di protocollo. La parola proxy compare per il pubblico del proxy inverso, non come limite di un canale aperto. Non la riscrivo.

Il documento del 2011 lega il protocollo a TCP e a una stretta di mano letta come Upgrade. La pagina su HTTP/3 non dice se quel canale viaggia su HTTP/3. Non lo dico io.

Esempio ipotetico

bottega.example è un nome di scuola. Non l'ho aperto. Non so se una sua pagina riceve un avviso più tardi. prova.bottega.example è l'altro nome di scuola. Non l'ho aperto. Non so se due persone modificano lo stesso testo.

Il documento del 2011 nomina la messaggistica e la modifica simultanea come usi del protocollo. Non sono bottega.example e non sono prova.bottega.example. Non assegno a questi nomi una stretta di mano riuscita, un codice 1001, uno stato 403, un cookie, un tunnel con codice 101, un 60 secondi, né un ritardo fra 0 e 5. Non ho misurato un avviso.

Che cosa questa pagina lascia stare

Non ho misurato un sito. Non ho aperto un canale. Il nome del protocollo sta nel testo, dopo la domanda. La copertina è nuova, perché la pagina è nuova. Non ho riscritto la pagina sul lavoro lungo, quella sulla copia di prova, quella sulla chiave, quella sulla compressione, quella sulla cartella, quella sulle misure e quella su HTTP/3.

Fonti lette il 3 novembre 2026. RFC 6455, dicembre 2011, copyright 2011, risposta delle 04:59:11 GMT senza last-modified, https://www.rfc-editor.org/rfc/rfc6455.txt. nginx, WebSocket proxying, last-modified 22 ottobre 2026 alle 11:23:19 GMT, risposta delle 04:59:21 GMT, https://nginx.org/en/docs/http/websocket.html. nginx, ngx_http_proxy_module, last-modified 22 ottobre 2026 alle 11:23:19 GMT, risposta delle 05:02:05 GMT, https://nginx.org/en/docs/http/ngx_http_proxy_module.html. MDN, WebSocket API, ultima modifica in pagina 22 ottobre 2026, last-modified 3 novembre 2026 alle 00:53:07 GMT, https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API. Pagina pubblica su HTTP/3, pubblicazione 3 ottobre 2026, aggiornata il 2 novembre 2026, https://www.roxxoitalia.com/blog/infrastruttura/http3-quic-alt-svc.