Redirigeix peticions HTTP seleccionades de Squid cap a HTTPS
Retorna una redirecció de client per a llocs coneguts compatibles amb HTTPS en lloc de canviar silenciosament cada URL d'origen HTTP o suposar que el proxy pot crear suport TLS a l'origen.
Squid pot demanar al navegador que torni a provar una URL HTTP seleccionada sobre HTTPS. La destinació ja ha de servir el recurs corresponent sobre HTTPS; executar Squid en una Raspberry Pi no crea aquesta capacitat al lloc web.
Per a la interfície url_rewrite_program de Squid 7, un helper pot retornar una redirecció de client com aquesta:
OK status=307 url="https://www.example.com/help"Aquesta és una resposta il·lustrativa d'un helper per a una petició coincident, no un programa helper complet. El navegador rep la redirecció i fa una petició nova a la URL HTTPS. Una URL fora de la política d'actualització pot rebre OK i quedar sense canvis.
Utilitza una llista coneguda de destinacions compatibles amb HTTPS i analitza la URL entrant. Conserva el camí i la query previstos, tingues en compte els ports explícits i tracta els mètodes de petició amb intenció. Substituir cegament cada prefix http suposa que cada origen té un servei HTTPS equivalent.
El helper ha de respondre cada línia d'entrada segons el protocol de la versió de Squid instal·lada. Si els canals helper simultanis estan activats, conserva l'identificador de canal a la resposta. L'antic exemple nu 301:URL no és intercanviable amb el format actual de result-and-key/value.
Tria una redirecció de client quan el navegador hagi de conèixer la URL nova. Una resposta rewrite-url, en canvi, demana a Squid que obtingui una URL diferent darrere la petició original del client, cosa que pot deixar les URL de l'aplicació i l'estat incoherents.
La petició HTTP inicial ja ha viatjat fins a Squid abans que el helper la pugui redirigir. Aquesta política no pot protegir retroactivament aquella petició. TLS comença a la connexió HTTPS posterior; un túnel CONNECT sol no proporciona cap xifratge.