WSS prin Squid nu este același lucru cu o simplă actualizare WebSocket
Separați WebSocket-urile criptate din interiorul CONNECT de tratarea HTTP Upgrade în clar într-un proxy de redirecționare.
Squid vede o cerere HTTP Upgrade sau doar un tunel care transportă trafic criptat? Asta determină dacă controalele sale HTTP Upgrade rezolvă defecțiunea.
| Calea obișnuită prin proxy explicit | Ce întâlnește Squid |
|---|---|
wss:// | De obicei CONNECT, urmat de TLS-ul destinației care transportă strângerea de mână WebSocket |
ws:// | O cerere HTTP Upgrade în clar pe care proxy-ul o poate procesa |
Controlul actualizărilor din Squid privește cererile pe care le procesează. Nu dezvăluie anteturile HTTP criptate dintr-un tunel WSS opac obișnuit. Interceptarea TLS sau altă tratare specială a proxy-ului schimbă vizibilitatea și poate aduce propriile cerințe de compatibilitate.
Pentru WSS, găsiți unde se oprește secvența: conexiunea la proxy, CONNECT acceptat, TLS verificat, apoi strângerea de mână a aplicației. O respingere înainte de TLS este o defecțiune diferită de o cerere Upgrade în clar refuzată.
Dacă este nevoie de o schimbare a politicii de actualizare, folosiți directiva pentru versiunea Squid instalată și permiteți în mod specific comportamentul necesar. Permiterea tuturor protocoalelor de actualizare lărgește politica dincolo de aplicația respectivă.
O cerere reușită de pagină HTTPS stabilește doar o parte a traseului. Traficul WebSocket de lungă durată poate eșua în continuare din cauza cerințelor aplicației, a duratei de viață a conexiunii sau a restricțiilor intermediarilor, chiar și pentru același nume de gazdă.