Miksi Squid kirjaa HTTPS-isännän mutta ei sivun polkua
Selittää puuttuvat HTTPS-polut tavallisissa Squid CONNECT -lokeissa käsittelemättä TLS-salakuuntelua rutiininomaisena lokiasetuksena.
Tietue shop.example:443:sta ei anna Squidille polkua /orders/42. CONNECT pyytää isäntää/porttia; sen jälkeen kohteen TLS kuljettaa HTTP-polkua tunnelin sisällä.
| Todiste | Tavallinen CONNECT-välitys |
|---|---|
| Kohdeisäntä/portti ja tunnelin tulos | Välityspalvelimen saatavilla. |
| Sisäinen HTTPS-polku ja sovelluksen pyyntö | Salattu asiakkaan ja verkkosivuston välillä. |
Selaimen URL-osuus, joka alkaa merkillä # | Pysyy yleensä asiakkaassa, myös välityspalvelimen lokin ulkopuolella. |
Lokimuoto voi tallentaa kenttiä, jotka Squidilla on, ei purkaa näkemättömiä viestejä. Tavallinen HTTP-välitys on erilaista, koska välittäjä vastaanottaa kyseisen HTTP-pyynnön. Yksityiskohtaisempi tuloste ei muuta CONNECT-rajaa.
Hallittu TLS-salakuuntelu muuttaa asiakkaan luottamusta ja hallinnollisia vaatimuksia. Se ei ole pieni lokikytkin eikä tarpeen tavalliselle IP:tä vaihtavalle välityspalvelimelle.
Jos sovellus on sinun ja tarvitset sivutason diagnostiikkaa, käytä sen lokeja tai asianmukaisesti suunniteltua asiakastelemetriaa. Välityspalvelinvirheissä säilytä kohdeisäntä, ajoitus, tila ja päättynyt yhteyden vaihe; ne paikantavat ongelman usein keräämättä yksityisiä sivupolkuja.