Voiko Squidin URL-uudelleenkirjoittaja muuttaa vastausten runkoja?
Pidä pyynnön URL:n valinta erillään vastausten mukauttamisesta ja TLS-salauksen purkamisesta, kun laajennat eteenpäin välittävää välityspalvelinta.
url_rewrite_program työskentelee pyynnön URL:ia koskevien päätösten parissa. Se vastaanottaa pyyntöä koskevat tiedot ja vastaa Squidin apuprotokollan kautta; se ei saa ladattua tiedostoa muokattavaksi ja palautettavaksi.
| Haluttu toimenpide | Olennainen raja |
|---|---|
| Selaimen uudelleenohjaus tai toisen pyyntö-URL:n valinta | URL-uudelleenkirjoitusapurin rooli pyyntövaiheessa |
| Näkyvän HTTP-vastauksen rungon muuttaminen | Vastausten mukauttamisratkaisu, kuten määritetty ICAP-vastausmuutos |
| HTTP:n lukeminen tavallisen CONNECT:n sisällä | Kohteen TLS on ensin lopetettava asianmukaisessa käyttöönottoratkaisussa |
| Sovelluksen salakirjoittaman tiedoston purkaminen | Tiedoston muoto, algoritmi ja avain riippumatta sen siirtotavasta |
Kaksi viimeistä riviä sekoitetaan helposti. Tavallinen HTTPS:n yli siirretty tiedosto on TLS:n suojaama. Sovelluksen salakirjoittama tiedosto voi pysyä salattuna vielä sen jälkeenkin, kun HTTPS on lopetettu. Mukauttamisrajapinnan valitseminen ei anna sovelluksen avainta eikä sen purkualgoritmia.
Tavallinen CONNECT välittää salattuja tunnelitavuja. URL-apuri ei paljasta sisempää vastausta; tarkastusta vaativa suunnittelu on selvitettävä, voidaanko ja pitäisikö tämä liikenne purkaa käyttöönotossa.
Missä Squid voi tarkastaa HTTP-viestin, vastausmuutospalvelu vastaa edelleen sisältökoodauksista, muuttuneista pituuksista ja virhetilanteiden toiminnasta. Valitse rajapinta sen jälkeen, kun muunnos on määritelty, sen sijaan että laajentaisit toimivaa URL-uudelleenkirjoitusesimerkkiä käsittelyvaiheeseen, jota se ei koskaan saa.