WSS gjennom Squid er ikkje det same som ei vanleg WebSocket-oppgradering
Skil krypterte WebSocket-ar inne i CONNECT frå handtering av vanleg HTTP Upgrade i ein videresendande proxy.
Ser Squid ein HTTP Upgrade-førespurnad, eller berre ein tunnel som ber kryptert trafikk? Det avgjer om HTTP Upgrade-kontrollane hans tek opp feilen.
| Vanleg eksplisitt proxy-løp | Kva Squid møter |
|---|---|
wss:// | Vanlegvis CONNECT, etterfølgt av TLS på målet som ber WebSocket-handtrykket |
ws:// | Ein vanleg HTTP Upgrade-førespurnad som proxyen kan handsame |
Oppgraderingskontrollen til Squid gjeld førespurnader han handsamar. Han avdekkjer ikkje krypterte HTTP-hovud inne i ein vanleg ugjennomsiktig WSS-tunnel. TLS-avlytting eller anna særskild proxyhandtering endrar synlegheita og kan føra med seg eigne kompatibilitetskrav.
For WSS, finn kvar sekvensen stoppar: tilkopling til proxyen, godteken CONNECT, stadfesta TLS, deretter handtrykket til applikasjonen. Ei avvising før TLS er ein annan feil enn ein avvist vanleg Upgrade-førespurnad.
Om ei endring i oppgraderingspolicyen er naudsynt, bruk direktivet for den installerte Squid-versjonen og tillat den naudsynte åtferda spesifikt. Å tillate alle oppgraderingsprotokollar utvidar policyen utover den aktuelle applikasjonen.
Ein vellukka HTTPS-sideførespurnad etablerer berre ein del av løpet. Langvarig WebSocket-trafikk kan framleis feila på krav frå applikasjonen, levetida til tilkoplinga eller avgrensingar hjå mellomledd, jamvel for same vertsnamn.