Per quanto tempo un tunnel CONNECT può restare aperto?
Distinguete la durata di un tunnel stabilito dal riutilizzo delle risposte HTTP, dalle politiche di inattività dell'intermediario e dalla sessione dell'applicazione di destinazione stessa.
CONNECT non promette un tunnel aperto a tempo indefinito. Dopo uno scambio riuscito, la connessione trasporta un flusso continuo di byte verso l'host e la porta richiesti. Può trasportare più scambi all'interno di una sessione TLS di destinazione finché i partecipanti e la rete la mantengono aperta.
Due limiti del proxy si comportano diversamente: il traffico può impedire la scadenza di un timer di inattività, ma non può estendere un limite di durata assoluto. Anche il protocollo di destinazione ha voce in capitolo. Un client HTTP interno può chiudere la propria connessione; un'applicazione WebSocket può terminare la propria sessione. Il proxy non può mantenere viva quella sessione di destinazione dopo.
Un tunnel è legato al suo bersaglio. Una volta che i byte del tunnel scorrono, la connessione non è più un normale canale di richieste HTTP su cui emettere un altro CONNECT per una destinazione non correlata. Il client ha bisogno di un'altra connessione o di un altro tunnel gestito dalla sua libreria.
Per un feed persistente, pianificate le riconnessioni con i meccanismi di vitalità e di connessione supportati dal client. Se si chiude dopo un silenzio, una politica di inattività è un indizio utile; se si chiude dopo una durata fissa nonostante il traffico, cercate invece un limite assoluto. Per un feed WebSocket, ripristinate anche lo stato dell'applicazione dopo la riconnessione.