WSS per Squid nėra tas pats kaip paprastas WebSocket atnaujinimas
Atskirkite šifruotus WebSocket CONNECT viduje nuo paprasto HTTP Upgrade apdorojimo tiesioginiame proxy.
Ar Squid mato HTTP Upgrade užklausą, ar tik tunelį su šifruotu srautu? Tai lemia, ar jo HTTP Upgrade valdikliai sprendžia gedimą.
| Įprastas tiesioginio proxy kelias | Su kuo susiduria Squid |
|---|---|
wss:// | Paprastai CONNECT, po to paskirties TLS, kuris perduoda WebSocket rankos paspaudimą |
ws:// | Paprasta HTTP Upgrade užklausa, kurią proxy gali apdoroti |
Squid atnaujinimo valdymas susijęs su užklausomis, kurias jis apdoroja. Jis neatskleidžia šifruotų HTTP antraščių įprastame nepermatomame WSS tunelyje. TLS perėmimas ar kitas specialus proxy apdorojimas keičia matomumą ir gali atnešti savo suderinamumo reikalavimus.
WSS atveju suraskite, kur seka sustoja: ryšys su proxy, priimtas CONNECT, patikrintas TLS, tada programos rankos paspaudimas. Atmetimas prieš TLS yra kitas gedimas nei atmesta paprasta Upgrade užklausa.
Jei reikia pakeisti atnaujinimo politiką, naudokite įdiegtos Squid versijos direktyvą ir konkrečiai leiskite reikiamą elgseną. Leidus visus atnaujinimo protokolus, politika išplečiama už konkrečios programos.
Sėkminga HTTPS puslapio užklausa nustato tik dalį kelio. Ilgai gyvuojantis WebSocket srautas vis tiek gali nepavykti dėl programos reikalavimų, ryšio trukmės ar tarpininkų apribojimų, net ir tam pačiam hosto vardui.