WSS tra Squid ne samas kiel ordinara WebSocket-ĝisdatigo
Apartigu ĉifritajn WebSocket-ojn ene de CONNECT de pritraktado de ordinara HTTP Upgrade en antaŭa prokura servilo.
Ĉu Squid vidas HTTP Upgrade-peton, aŭ nur tunelon portantan ĉifritan trafikon? Tio determinas ĉu ĝiaj HTTP Upgrade-kontroloj traktas la malsukceson.
| Ordinara eksplicita prokura vojo | Kion Squid renkontas |
|---|---|
wss:// | Kutime CONNECT, sekvata de cela TLS portanta la WebSocket-manpremon |
ws:// | Ordinara HTTP Upgrade-peto, kiun la prokuro povas pritrakti |
La ĝisdatiga kontrolo de Squid rilatas al petoj, kiujn ĝi pritraktas. Ĝi ne malkaŝas ĉifritajn HTTP-kapojn ene de ordinara maldiafana WSS-tunelo. TLS-interkapto aŭ alia speciala prokura pritraktado ŝanĝas videblecon kaj povas enkonduki proprajn kongruecajn postulojn.
Por WSS, trovu kie la sinsekvo haltas: konekto al la prokuro, akceptita CONNECT, kontrolita TLS, poste la aplika manpremo. Rifuzo antaŭ TLS estas alia malsukceso ol malakceptita ordinara Upgrade-peto.
Se ŝanĝo de ĝisdatiga politiko necesas, uzu la direktivon por la instalita eldono de Squid kaj permesu la bezonatan konduton specife. Permesi ĉiujn ĝisdatigajn protokolojn vastigas la politikon preter la koncerna aplikaĵo.
Sukcesa peto de HTTPS-paĝo establas nur parton de la vojo. Longdaŭra WebSocket-trafiko ankoraŭ povas malsukcesi pro aplikaĵaj postuloj, konekta vivodaŭro aŭ limigoj de perantoj, eĉ por la sama gastigantnomo.