Valittujen HTTP-pyyntöjen uudelleenohjaus Squidista HTTPS:ään
Palauta asiakasohjaus tunnetuille HTTPS-kykyisille sivustoille sen sijaan, että muuttaisit hiljaa jokaisen HTTP-lähde-URLin tai olettaisit välityspalvelimen voivan luoda TLS-tuen lähteeseen.
Squid voi pyytää selainta yrittämään valittua HTTP-URLia uudelleen HTTPS:n kautta. Kohteen on jo tarjottava vastaava resurssi HTTPS:n kautta; Squidin ajaminen Raspberry Pi -laitteella ei luo tätä kykyä verkkosivustolle.
Squid 7:n url_rewrite_program-rajapinnalle helper voi palauttaa asiakasohjauksen esimerkiksi näin:
OK status=307 url="https://www.example.com/help"Tämä on yksi havainnollistava helper-vastaus vastaavalle pyynnölle, ei täydellinen helper-ohjelma. Selain vastaanottaa uudelleenohjauksen ja tekee uuden pyynnön HTTPS-URLiin. Päivityskäytännön ulkopuolinen URL voi saada OK-vastauksen ja pysyä muuttumattomana.
Käytä tunnettua luetteloa HTTPS-kykyisistä kohteista ja jäsennä saapuva URL. Säilytä aiottu polku ja query, huomioi eksplisiittiset portit ja käsittele pyyntömenetelmät tietoisesti. Jokaisen http-etuliitteen sokea korvaaminen olettaa, että jokaisella lähteellä on vastaava HTTPS-palvelu.
Helperin on vastattava jokaiseen syöttöriviin asennetun Squid-version protokollalla. Jos samanaikaiset helper-kanavat ovat käytössä, säilytä kanavatunniste vastauksessa. Vanha pelkkä 301:URL-esimerkki ei ole vaihdettavissa nykyiseen result-and-key/value-muotoon.
Valitse asiakasohjaus, kun selaimen pitäisi tietää uusi URL. rewrite-url-vastaus sen sijaan pyytää Squidia hakemaan toisen URLin asiakkaan alkuperäisen pyynnön taakse, mikä voi jättää sovelluksen URLit ja tilan epäjohdonmukaisiksi.
Alkuperäinen HTTP-pyyntö on jo matkannut Squidille ennen kuin helper voi ohjata sen uudelleen. Tämä käytäntö ei voi suojata kyseistä pyyntöä jälkikäteen. TLS alkaa seuraavassa HTTPS-yhteydessä; pelkkä CONNECT-tunneli ei tarjoa salausta.