WSS przez Squid nie jest tym samym co zwykłe uaktualnienie WebSocket
Oddziel szyfrowane WebSocket wewnątrz CONNECT od obsługi zwykłego HTTP Upgrade w proxy przekazującym.
Czy Squid widzi żądanie HTTP Upgrade, czy tylko tunel przenoszący zaszyfrowany ruch? To decyduje, czy jego mechanizmy HTTP Upgrade rozwiązują problem.
| Zwykła ścieżka jawnego proxy | Z czym spotyka się Squid |
|---|---|
wss:// | Zwykle CONNECT, po którym następuje TLS celu przenoszący uścisk dłoni WebSocket |
ws:// | Zwykłe żądanie HTTP Upgrade, które proxy może przetworzyć |
Kontrola uaktualnień Squida dotyczy żądań, które przetwarza. Nie ujawnia zaszyfrowanych nagłówków HTTP wewnątrz zwykłego nieprzezroczystego tunelu WSS. Przechwytywanie TLS lub inna specjalna obsługa proxy zmienia widoczność i może wprowadzić własne wymagania zgodności.
W przypadku WSS ustal, gdzie sekwencja się zatrzymuje: połączenie z proxy, zaakceptowany CONNECT, zweryfikowany TLS, następnie uścisk dłoni aplikacji. Odrzucenie przed TLS to inna awaria niż odrzucone zwykłe żądanie Upgrade.
Jeśli potrzebna jest zmiana polityki uaktualnień, użyj dyrektywy dla zainstalowanej wersji Squida i wyraźnie zezwól na wymagane zachowanie. Zezwolenie na wszystkie protokoły uaktualnień rozszerza politykę poza daną aplikację.
Udane żądanie strony HTTPS ustanawia tylko część ścieżki. Długotrwały ruch WebSocket nadal może zawodzić z powodu wymagań aplikacji, czasu życia połączenia lub ograniczeń pośredników, nawet dla tej samej nazwy hosta.