I-redirect ang mga piling HTTP request mula sa Squid patungong HTTPS

Maaaring hilingin ng Squid sa browser na subukang muli ang isang piling HTTP URL sa pamamagitan ng HTTPS. Dapat na ibinibigay na ng destinasyon ang kaukulang resource sa HTTPS; ang pagpapatakbo ng Squid sa Raspberry Pi ay hindi lumilikha ng kakayahang iyon sa website.

Para sa interface na url_rewrite_program ng Squid 7, maaaring magbalik ang helper ng client redirect na tulad nito:

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

Isa itong halimbawang helper na tugon para sa tugmang kahilingan, hindi isang kumpletong helper program. Natatanggap ng browser ang redirect at gumagawa ng bagong kahilingan sa HTTPS URL. Ang URL sa labas ng patakaran sa pag-upgrade ay maaaring makatanggap ng OK at manatiling hindi nabago.

Gumamit ng kilalang listahan ng mga destinasyong may kakayahang HTTPS at suriin ang papasok na URL. Panatilihin ang nilalayong landas at query, isaalang-alang ang malinaw na port, at sinasadyang pangasiwaan ang mga paraan ng kahilingan. Ang bulag na pagpapalit ng bawat http prefix ay nagpapalagay na ang bawat origin ay may katumbas na serbisyong HTTPS.

Dapat sagutin ng helper ang bawat linya ng input ayon sa protocol ng naka-install na bersyon ng Squid. Kung pinagana ang magkakaugnay na helper channel, panatilihin ang identifier ng channel sa tugon. Ang lumang hubad na halimbawang 301:URL ay hindi mapagpapalit sa kasalukuyang format na result-and-key/value.

Pumili ng client redirect kapag dapat malaman ng browser ang bagong URL. Ang tugon na rewrite-url sa halip ay humihiling sa Squid na kumuha ng ibang URL sa likod ng orihinal na kahilingan ng client, na maaaring mag-iwan sa mga URL at estado ng application na hindi magkatugma.

Ang paunang HTTP kahilingan ay nakarating na sa Squid bago pa ito ma-redirect ng helper. Hindi maaaring protektahan ng patakarang ito ang kahilingang iyon nang paurong. Nagsisimula ang TLS sa susunod na koneksyon sa HTTPS; ang CONNECT tunnel lamang ay walang ibinibigay na encryption.