Omdiriger utvalde HTTP-førespurnader frå Squid til HTTPS

Squid kan be ein nettlesar prøve ein utvald HTTP-URL på nytt over HTTPS. Målet må allereie levere den tilhøyrande ressursen over HTTPS; å køyre Squid på ein Raspberry Pi skaper ikkje denne eigenskapen på nettstaden.

For url_rewrite_program-grensesnittet til Squid 7 kan ein helper returnere ei klientomdirigering som denne:

OK status=307 url="https://www.example.com/help"

Dette er eitt illustrerande helpersvar for ein samsvarande førespurnad, ikkje eit fullstendig helperprogram. Nettlesaren tek imot omdirigeringa og sender ein ny førespurnad til HTTPS-URL-en. Ein URL utanfor oppgraderingspolicyen kan få OK og vere uendra.

Bruk ei kjend liste over HTTPS-kompatible mål og analyser den innkomande URL-en. Behald den tiltenkte banen og queryen, ta omsyn til eksplisitte portar og handsam førespurnadsmetodar medvite. Blind erstatting av kvart http-prefiks føreset at kvar opphav har ei tilsvarande HTTPS-teneste.

Helperen må svare på kvar inndatalinje etter protokollen til den installerte Squid-versjonen. Viss samtidige helperkanalar er aktiverte, må kanalidentifikatoren haldast i svaret. Det gamle berre 301:URL-dømet kan ikkje bytast ut med det noverande result-and-key/value-formatet.

Vel ei klientomdirigering når nettlesaren bør kjenne den nye URL-en. Eit rewrite-url-svar ber i staden Squid hente ein annan URL bak den opphavlege førespurnaden til klienten, noko som kan la URL-ane og tilstanden til applikasjonen vere inkonsistente.

Den første HTTP-førespurnaden har allereie reist til Squid før helperen kan omdirigere han. Denne policyen kan ikkje verne den førespurnaden i ettertid. TLS byrjar på den neste HTTPS-tilkoplinga; ein CONNECT-tunnel åleine gir inga kryptering.