WSS prek Squida ni enako kot običajna nadgradnja WebSocket
Ločite šifrirane WebSocket v CONNECT od obdelave običajnega HTTP Upgrade v posredniškem proxyju.
Ali Squid vidi zahtevo HTTP Upgrade ali le tunel s šifriranim prometom? To določa, ali njegove kontrole HTTP Upgrade rešujejo napako.
| Običajna pot skozi eksplicitni proxy | S čim se Squid srečuje |
|---|---|
wss:// | Običajno CONNECT, nato TLS cilja, ki nosi rokovanje WebSocket |
ws:// | Običajna zahteva HTTP Upgrade, ki jo proxy lahko obdela |
Nadzor nadgradnje v Squidu zadeva zahteve, ki jih obdeluje. Ne razkriva šifriranih glav HTTP znotraj običajnega neprosojnega tunela WSS. Prestreznica TLS ali druga posebna obdelava proxyja spremeni vidnost in lahko prinese lastne zahteve glede združljivosti.
Pri WSS poiščite, kje se zaporedje ustavi: povezava s proxyjem, sprejet CONNECT, preverjen TLS, nato rokovanje aplikacije. Zavrnitev pred TLS je drugačna napaka od zavrnjene običajne zahteve Upgrade.
Če je potrebna sprememba politike nadgradnje, uporabite direktivo za nameščeno različico Squida in posebej dovolite zahtevano vedenje. Dovoljenje vseh protokolov nadgradnje razširi politiko prek določene aplikacije.
Uspešna zahteva za stran HTTPS vzpostavi le del poti. Dolgotrajen promet WebSocket lahko še vedno ne uspe zaradi zahtev aplikacije, življenjske dobe povezave ali omejitev posrednikov, tudi za isto ime gostitelja.