Reindirizza richieste HTTP selezionate da Squid a HTTPS

Squid può chiedere a un browser di riprovare un URL HTTP selezionato tramite HTTPS. La destinazione deve già servire la risorsa corrispondente tramite HTTPS; eseguire Squid su un Raspberry Pi non crea questa capacità sul sito web.

Per l'interfaccia url_rewrite_program di Squid 7, un helper può restituire un reindirizzamento client come questo:

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

Questa è una risposta illustrativa di un helper per una richiesta corrispondente, non un programma helper completo. Il browser riceve il reindirizzamento ed effettua una nuova richiesta all'URL HTTPS. Un URL fuori dalla politica di aggiornamento può ricevere OK e rimanere invariato.

Usa un elenco noto di destinazioni compatibili con HTTPS e analizza l'URL in ingresso. Conserva il percorso e la query previsti, considera le porte esplicite e gestisci i metodi di richiesta con consapevolezza. Sostituire ciecamente ogni prefisso http presuppone che ogni origine abbia un servizio HTTPS equivalente.

L'helper deve rispondere a ogni riga di input secondo il protocollo della versione di Squid installata. Se sono abilitati canali helper concorrenti, conserva l'identificatore del canale nella risposta. Il vecchio esempio nudo 301:URL non è intercambiabile con il formato attuale result-and-key/value.

Scegli un reindirizzamento client quando il browser deve conoscere il nuovo URL. Una risposta rewrite-url invece chiede a Squid di recuperare un URL diverso dietro la richiesta originale del client, il che può lasciare incoerenti gli URL dell'applicazione e il suo stato.

La richiesta HTTP iniziale ha già raggiunto Squid prima che l'helper possa reindirizzarla. Questa politica non può proteggere retroattivamente quella richiesta. TLS inizia sulla connessione HTTPS successiva; un tunnel CONNECT da solo non fornisce alcuna crittografia.