Redirecționarea cererilor HTTP selectate de la Squid către HTTPS
Returnați o redirecționare de client pentru site-uri cunoscute compatibile cu HTTPS în loc să modificați în tăcere fiecare URL de origine HTTP sau să presupuneți că proxy-ul poate crea suport TLS la origine.
Squid poate cere unui browser să reîncerce un URL HTTP selectat prin HTTPS. Destinația trebuie să servească deja resursa corespunzătoare prin HTTPS; rularea Squid pe un Raspberry Pi nu creează această capacitate pe site.
Pentru interfața url_rewrite_program din Squid 7, un helper poate returna o redirecționare de client precum aceasta:
OK status=307 url="https://www.example.com/help"Aceasta este o singură reacție ilustrativă a helper-ului pentru o cerere potrivită, nu un program helper complet. Browserul primește redirecționarea și face o cerere nouă către URL-ul HTTPS. Un URL din afara politicii de actualizare poate primi OK și poate rămâne neschimbat.
Folosiți o listă cunoscută de destinații compatibile cu HTTPS și analizați URL-ul de intrare. Păstrați calea și query-ul dorite, țineți cont de porturile explicite și tratați metodele cererii cu deliberare. Înlocuirea orbească a fiecărui prefix http presupune că fiecare origine are un serviciu HTTPS echivalent.
Helper-ul trebuie să răspundă fiecărei linii de intrare conform protocolului versiunii Squid instalate. Dacă canalele helper concurente sunt activate, păstrați identificatorul canalului în răspuns. Vechea mostră simplă 301:URL nu este interschimbabilă cu formatul actual result-and-key/value.
Alegeți o redirecționare de client când browserul ar trebui să cunoască noul URL. Un răspuns rewrite-url cere în schimb Squid să aducă un alt URL în spatele cererii originale a clientului, ceea ce poate lăsa URL-urile aplicației și starea inconsecvente.
Cererea HTTP inițială a ajuns deja la Squid înainte ca helper-ul să o poată redirecționa. Această politică nu poate proteja retroactiv acea cerere. TLS începe pe următoarea conexiune HTTPS; doar un tunel CONNECT nu oferă nicio criptare.