WSS gennem Squid er ikke det samme som en almindelig WebSocket-opgradering
Adskil krypterede WebSockets inde i CONNECT fra håndtering af almindelig HTTP Upgrade i en videresendende proxy.
Ser Squid en HTTP Upgrade-anmodning, eller kun en tunnel med krypteret trafik? Det afgør, om dens HTTP Upgrade-kontroller adresserer fejlen.
| Almindelig eksplicit proxy-vej | Hvad Squid møder |
|---|---|
wss:// | Typisk CONNECT, efterfulgt af destinations-TLS, der bærer WebSocket-håndtrykket |
ws:// | En almindelig HTTP Upgrade-anmodning, som proxyen kan behandle |
Squids opgraderingskontrol vedrører de anmodninger, den behandler. Den afslører ikke krypterede HTTP-headere inde i en almindelig uigennemsigtig WSS-tunnel. TLS-aflytning eller anden særlig proxybehandling ændrer synligheden og kan medføre egne kompatibilitetskrav.
For WSS skal du finde ud af, hvor sekvensen stopper: forbindelse til proxyen, accepteret CONNECT, verificeret TLS, derefter applikationens håndtryk. En afvisning før TLS er en anden fejl end en afvist almindelig Upgrade-anmodning.
Hvis der er brug for en ændring af opgraderingspolitikken, skal du bruge direktivet til den installerede Squid-version og udtrykkeligt tillade den nødvendige adfærd. At tillade alle opgraderingsprotokoller udvider politikken ud over den konkrete applikation.
En vellykket HTTPS-sideanmodning etablerer kun en del af vejen. Langvarig WebSocket-trafik kan stadig fejle på grund af applikationskrav, forbindelsens levetid eller mellemledsbegrænsninger, selv for det samme værtsnavn.