Omdiriger udvalgte HTTP-anmodninger fra Squid til HTTPS
Returner en klientomdirigering for kendte HTTPS-kompatible websteder i stedet for lydløst at ændre hver HTTP-oprindelses-URL eller antage, at proxyen kan skabe TLS-understøttelse ved oprindelsen.
Squid kan bede en browser om at gentage en udvalgt HTTP-URL over HTTPS. Destinationen skal allerede levere den tilsvarende ressource over HTTPS; at køre Squid på en Raspberry Pi skaber ikke den egenskab på webstedet.
Til Squid 7's url_rewrite_program-grænseflade kan en helper returnere en klientomdirigering som denne:
OK status=307 url="https://www.example.com/help"Dette er ét illustrativt helpersvar for en matchende anmodning, ikke et komplet helperprogram. Browseren modtager omdirigeringen og sender en ny anmodning til HTTPS-URL'en. En URL uden for opgraderingspolitikken kan få OK og forblive uændret.
Brug en kendt liste over HTTPS-kompatible destinationer, og pars den indgående URL. Bevar den tilsigtede sti og query, tag højde for eksplicitte porte, og håndtér anmodningsmetoder bevidst. Blind udskiftning af hvert http-præfiks antager, at hver oprindelse har en tilsvarende HTTPS-tjeneste.
Helperen skal besvare hver inputlinje efter protokollen i den installerede Squid-version. Hvis samtidige helperkanaler er aktiveret, skal kanalidentifikatoren bevares i svaret. Det gamle bare 301:URL-eksempel kan ikke udskiftes med det nuværende result-and-key/value-format.
Vælg en klientomdirigering, når browseren skal kende den nye URL. Et rewrite-url-svar beder i stedet Squid hente en anden URL bag klientens oprindelige anmodning, hvilket kan efterlade applikationens URL'er og tilstand inkonsistente.
Den indledende HTTP-anmodning har allerede rejst til Squid, før helperen kan omdirigere den. Denne politik kan ikke beskytte den anmodning bagudrettet. TLS starter på den efterfølgende HTTPS-forbindelse; en CONNECT-tunnel alene giver ingen kryptering.