Redirixir solicitudes HTTP seleccionadas de Squid a HTTPS
Devolve unha redirección de cliente para sitios coñecidos compatibles con HTTPS en vez de cambiar silenciosamente cada URL de orixe HTTP ou supoñer que o proxy pode crear soporte TLS na orixe.
Squid pode pedir a un navegador que reintente unha URL HTTP seleccionada sobre HTTPS. O destino xa debe servir o recurso correspondente sobre HTTPS; executar Squid nunha Raspberry Pi non crea esa capacidade no sitio web.
Para a interface url_rewrite_program de Squid 7, un helper pode devolver unha redirección de cliente coma esta:
OK status=307 url="https://www.example.com/help"Esta é unha resposta ilustrativa de helper para unha solicitude coincidente, non un programa helper completo. O navegador recibe a redirección e fai unha nova solicitude á URL HTTPS. Unha URL fóra da política de actualización pode recibir OK e quedar sen cambios.
Use unha lista coñecida de destinos compatibles con HTTPS e analice a URL entrante. Conserve a ruta e a query previstas, teña en conta os portos explícitos e trate os métodos de solicitude con deliberación. Substituír a cegas cada prefixo http supón que cada orixe ten un servizo HTTPS equivalente.
O helper debe responder a cada liña de entrada segundo o protocolo da versión de Squid instalada. Se os canles de helper simultáneos están activados, conserve o identificador de canle na resposta. O antigo exemplo simple 301:URL non é intercambiable co formato actual result-and-key/value.
Escolla unha redirección de cliente cando o navegador deba coñecer a nova URL. Unha resposta rewrite-url, en cambio, pide a Squid obter outra URL detrás da solicitude orixinal do cliente, o que pode deixar as URL da aplicación e o estado inconsistentes.
A solicitude HTTP inicial xa viaxou ata Squid antes de que o helper poida redirixila. Esta política non pode protexer retroactivamente esa solicitude. TLS comeza na conexión HTTPS posterior; un túnel CONNECT por si só non proporciona cifrado.