WSS përmes Squid nuk është njësoj si një përmirësim i thjeshtë WebSocket
Ndani WebSocket-et e kriptuara brenda CONNECT nga trajtimi i HTTP Upgrade në tekst të thjeshtë në një proxy përpara.
A e sheh Squid një kërkesë HTTP Upgrade, apo vetëm një tunel që mbart trafik të kriptuar? Kjo përcakton nëse kontrollet e tij HTTP Upgrade e trajtojnë defektin.
| Rruga e zakonshme e proxy-t eksplicit | Me çfarë përballet Squid |
|---|---|
wss:// | Zakonisht CONNECT, i ndjekur nga TLS i destinacionit që mbart shtrëngimin e duarve WebSocket |
ws:// | Një kërkesë HTTP Upgrade në tekst të thjeshtë që proxy-i mund ta përpunojë |
Kontrolli i përmirësimit i Squid-it ka të bëjë me kërkesat që ai përpunon. Ai nuk i zbulon titujt HTTP të kriptuar brenda një tuneli normalisht të errët WSS. Përgjimi TLS ose një trajtim tjetër i veçantë i proxy-t ndryshon dukshmërinë dhe mund të sjellë kërkesat e veta të përputhshmërisë.
Për WSS, gjeni ku ndalet sekuenca: lidhja me proxy-n, CONNECT i pranuar, TLS i verifikuar, pastaj shtrëngimi i duarve i aplikacionit. Një refuzim para TLS është një defekt tjetër nga një kërkesë e refuzuar Upgrade në tekst të thjeshtë.
Nëse nevojitet një ndryshim i politikës së përmirësimit, përdorni direktivën për versionin e instaluar të Squid-it dhe lejoni posaçërisht sjelljen e nevojshme. Lejimi i të gjitha protokolleve të përmirësimit e zgjeron politikën përtej aplikacionit konkret.
Një kërkesë e suksesshme faqe HTTPS vendos vetëm një pjesë të rrugës. Trafiku WebSocket afatgjatë mund të dështojë ende për shkak të kërkesave të aplikacionit, jetëgjatësisë së lidhjes ose kufizimeve të ndërmjetësve, edhe për të njëjtin emër hosti.