Redirekti elektitajn HTTP-petojn de Squid al HTTPS
Redonu klientan redirekton por konataj HTTPS-kapablaj retejoj anstataŭ silente ŝanĝi ĉiun HTTP-origonan URL-on aŭ supozi, ke la prokurilo povas krei TLS-subtenon ĉe la origino.
Squid povas peti retumilon reprovi elektitan HTTP-URL-on per HTTPS. La celo jam devas liveri la respondan rimedon per HTTPS; ruli Squid sur Raspberry Pi ne kreas tiun kapablon ĉe la retejo.
Por la interfaco url_rewrite_program de Squid 7, helpprogramo povas redoni klientan redirekton kiel ĉi tio:
OK status=307 url="https://www.example.com/help"Ĉi tio estas unu ilustra helpprograma respondo por kongrua peto, ne kompleta helpprogramo. La retumilo ricevas la redirekton kaj faras novan peton al la HTTPS-URL. URL ekster la ĝisdatiga politiko povas ricevi OK kaj resti senŝanĝa.
Uzu konatan liston de HTTPS-kapablaj celoj kaj analizu la envenantan URL-on. Konservu la celitan vojon kaj query, konsideru eksplicitajn pordojn, kaj traktu petmetodojn konscie. Blinde anstataŭigi ĉiun http-prefikson supozas, ke ĉiu origino havas ekvivalentan HTTPS-servon.
La helpprogramo devas respondi ĉiun eniglinion laŭ la protokolo de la instalita Squid-versio. Se samtempaj helpkanaloj estas ebligitaj, konservu la kanalan identigilon en la respondo. La malnova nuda ekzemplo 301:URL ne estas interŝanĝebla kun la nuna formato result-and-key/value.
Elektu klientan redirekton kiam la retumilo devus scii la novan URL-on. Respondo rewrite-url anstataŭe petas al Squid akiri alian URL-on malantaŭ la origina peto de la kliento, kio povas lasi aplikaĵajn URL-ojn kaj staton malkonsekvencaj.
La komenca HTTP-peto jam vojaĝis al Squid antaŭ ol la helpprogramo povas redirekti ĝin. Ĉi tiu politiko ne povas retroaktive protekti tiun peton. TLS komenciĝas ĉe la sekva HTTPS-konekto; nur CONNECT-tunelo tute ne provizas ĉifradon.