Omdirigera utvalda HTTP-förfrågningar från Squid till HTTPS
Returnera en klientomdirigering för kända HTTPS-kompatibla webbplatser i stället för att tyst ändra varje HTTP-ursprungs-URL eller anta att proxyn kan skapa TLS-stöd vid ursprunget.
Squid kan be en webbläsare att försöka igen med en vald HTTP-URL över HTTPS. Målet måste redan leverera motsvarande resurs över HTTPS; att köra Squid på en Raspberry Pi skapar inte den förmågan på webbplatsen.
För Squid 7:s url_rewrite_program-gränssnitt kan en helper returnera en klientomdirigering som denna:
OK status=307 url="https://www.example.com/help"Detta är ett illustrativt helpersvar för en matchande begäran, inte ett komplett helperprogram. Webbläsaren tar emot omdirigeringen och gör en ny begäran till HTTPS-URL:en. En URL utanför uppgraderingspolicyn kan få OK och förbli oförändrad.
Använd en känd lista över HTTPS-kompatibla mål och analysera den inkommande URL:en. Bevara den avsedda sökvägen och queryn, ta hänsyn till explicita portar och hantera begäransmetoder medvetet. Blind ersättning av varje http-prefix förutsätter att varje ursprung har en likvärdig HTTPS-tjänst.
Helpern måste svara på varje indatarad enligt protokollet för den installerade Squid-versionen. Om samtidiga helperkanaler är aktiverade ska kanalidentifikatorn bevaras i svaret. Det gamla bara 301:URL-exemplet är inte utbytbart mot det nuvarande result-and-key/value-formatet.
Välj en klientomdirigering när webbläsaren bör känna till den nya URL:en. Ett rewrite-url-svar ber i stället Squid hämta en annan URL bakom klientens ursprungliga begäran, vilket kan lämna applikationens URL:er och tillstånd inkonsekventa.
Den första HTTP-begäran har redan rest till Squid innan helpern kan omdirigera den. Denna policy kan inte skydda den begäran i efterhand. TLS börjar på nästa HTTPS-anslutning; en CONNECT-tunnel ensam ger ingen kryptering.