Ridrejto kërkesat HTTP të zgjedhura nga Squid në HTTPS

Squid mund t'i kërkojë një shfletuesi të riprovojë një URL HTTP të zgjedhur përmes HTTPS. Destinacioni duhet të ofrojë tashmë burimin përkatës përmes HTTPS; ekzekutimi i Squid në një Raspberry Pi nuk e krijon atë aftësi në faqen e internetit.

Për ndërfaqen url_rewrite_program të Squid 7, një helper mund të kthejë një ridrejtim klienti si ky:

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

Ky është një përgjigje ilustruese helper për një kërkesë që përputhet, jo një program helper i plotë. Shfletuesi merr ridrejtimin dhe bën një kërkesë të re drejt URL-së HTTPS. Një URL jashtë politikës së përmirësimit mund të marrë OK dhe të mbetet e pandryshuar.

Përdorni një listë të njohur destinacionesh të afta për HTTPS dhe analizoni URL-në hyrëse. Ruani shtegun dhe query-n e synuar, merrni parasysh portat e shprehura dhe trajtoni metodat e kërkesës me vetëdije. Zëvendësimi i verbër i çdo prefiksi http supozon se çdo origjinë ka një shërbim HTTPS ekuivalent.

Helper duhet t'i përgjigjet çdo rreshti hyrjeje sipas protokollit të versionit të instaluar të Squid. Nëse kanalet helper të njëkohshme janë të aktivizuara, ruani identifikuesin e kanalit në përgjigje. Shembulli i vjetër i zhveshur 301:URL nuk është i këmbyeshëm me formatin aktual result-and-key/value.

Zgjidhni një ridrejtim klienti kur shfletuesi duhet ta dijë URL-në e re. Një përgjigje rewrite-url në vend të kësaj kërkon që Squid të sjellë një URL tjetër pas kërkesës origjinale të klientit, gjë që mund t'i lërë URL-të e aplikacionit dhe gjendjen e tij jo konsistente.

Kërkesa fillestare HTTP ka udhëtuar tashmë drejt Squid përpara se helper të mund ta ridrejtojë atë. Kjo politikë nuk mund ta mbrojë atë kërkesë në mënyrë të kundërveprimit. TLS fillon në lidhjen e ardhshme HTTPS; një tunel CONNECT i vetëm nuk ofron asnjë enkriptim.