Si tratta di HTTP keep-alive, che consente a più richieste di risorse di passare attraverso una singola sessione TCP (e, con SSL, una singola sessione SSL). Ciò è di grande importanza per le prestazioni di un sito SSL, poiché senza keep-alive sarebbe necessaria una stretta di mano SSL per ogni risorsa richiesta.
Quindi, la preoccupazione qui è una grande sessione keep-alive dal client fino al server back-end. È una cosa importante per le prestazioni e, come è ovvio, per i moderni server HTTP, ma questa patch dice che non la supporta. Diamo un'occhiata al perché ...
Una sessione keep-alive è solo più richieste una dopo l'altra: una volta che il server termina la sua risposta a una richiesta, il server non invia un FINpacchetto per terminare la sessione TCP; il client può semplicemente inviare un altro batch di intestazioni.
Per capire cosa sta facendo quella patch, ecco un esempio di conversazione keep-alive:
Cliente:
GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Server:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>
Ecco dove si fermerebbe una connessione non keep-alive. Ma keep-alive consente al client di licenziarne un altro:
GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Per l'ID client nel proxy, alcuni proxy inversi possono aggiungere X-Forwarded-Fornell'intestazione in ogni richiesta client. Ciò indica al server upstream da dove proviene la richiesta (anziché ogni richiesta avviata dall'IP del proxy inverso), per la sanità mentale nella registrazione e altre esigenze dell'applicazione.
L' X-Forwarded-Forintestazione deve essere iniettata in ogni richiesta di risorse client inviata attraverso la connessione keep-alive, poiché le intestazioni complete vengono inviate ogni volta; la gestione X-Forwarded-Fordell'intestazione e la traduzione in essa essendo l'IP "reale" della richiesta viene eseguito su una base per richiesta, non per sessione TCP-keep-alive. Ehi, forse c'è un fantastico software di proxy inverso là fuori che utilizza una singola sessione keep-alive per soddisfare le richieste di più client.
Questo è dove questa patch fallisce.
La patch in quel sito controlla il buffer della sessione TCP per la fine della prima serie di intestazioni HTTP nello stream e inietta la nuova intestazione nello stream dopo la fine della prima serie di intestazioni. Al termine, considera il X-Forwarded-Forlavoro svolto e interrompe la scansione per la fine di nuovi set di intestazioni. Questo metodo non è a conoscenza di tutte le future intestazioni che arrivano tramite richieste successive.
Non posso davvero biasimarli; stunnel non è stato realizzato per gestire e tradurre il contenuto dei suoi flussi.
L'effetto che ciò avrebbe sul tuo sistema è che la prima richiesta di un flusso keep-alive otterrà l' X-Forwarded-Forintestazione iniettata correttamente e tutte le richieste successive funzioneranno bene, ma non avranno l'intestazione.
A meno che non ci sia un'altra patch di iniezione di intestazione là fuori che può gestire più richieste client per connessione (o ottenere questa ottimizzata con l'aiuto dei nostri amici su Stack Overflow), potrebbe essere necessario esaminare altre opzioni per la terminazione SSL.