ປ່ຽນເສັ້ນທາງຄຳຮ້ອງ HTTP ທີ່ເລືອກຈາກ Squid ໄປ HTTPS
ສົ່ງການປ່ຽນເສັ້ນທາງຝັ່ງລູກຄ້າສຳລັບເວັບທີ່ຮູ້ຈັກວ່າຮອງຮັບ HTTPS ແທນການປ່ຽນທຸກ HTTP origin URL ແບບງຽບໆ ຫຼື ສົມມຸດວ່າ proxy ສ້າງການຮອງຮັບ TLS ຢູ່ຕົ້ນທາງໄດ້.
Squid ສາມາດຂໍໃຫ້ browser ລອງ HTTP URL ທີ່ເລືອກຄືນໃໝ່ຜ່ານ HTTPS. ປາຍທາງຕ້ອງໄດ້ໃຫ້ບໍລິການຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງຜ່ານ HTTPS ຢູ່ແລ້ວ; ການແລ່ນ Squid ເທິງ Raspberry Pi ບໍ່ໄດ້ສ້າງຄວາມສາມາດນັ້ນຢູ່ເວັບໄຊ.
ສຳລັບອິນເຕີເຟສ url_rewrite_program ຂອງ Squid 7, helper ສາມາດສົ່ງການປ່ຽນເສັ້ນທາງຝັ່ງລູກຄ້າເຊັ່ນນີ້:
OK status=307 url="https://www.example.com/help"ນີ້ແມ່ນຄຳຕອບ helper ຕົວຢ່າງໜຶ່ງສຳລັບຄຳຮ້ອງທີ່ກົງກັນ ບໍ່ແມ່ນໂປແກຣມ helper ເຕັມຮູບແບບ. Browser ໄດ້ຮັບການປ່ຽນເສັ້ນທາງ ແລະ ສົ່ງຄຳຮ້ອງໃໝ່ໄປຍັງ HTTPS URL. URL ທີ່ຢູ່ນອກນະໂຍບາຍການອັບເກຣດອາດໄດ້ຮັບ OK ແລະ ບໍ່ປ່ຽນແປງ.
ໃຊ້ລາຍຊື່ປາຍທາງທີ່ຮູ້ຈັກວ່າຮອງຮັບ HTTPS ແລະ ວິເຄາະ URL ທີ່ເຂົ້າມາ. ຮັກສາເສັ້ນທາງ ແລະ query ທີ່ຕັ້ງໃຈ, ຄິດເຖິງ port ທີ່ລະບຸໄວ້ ແລະ ຈັດການວິທີການຮ້ອງຢ່າງມີເຈດຕະນາ. ການປ່ຽນທຸກ http prefix ແບບຕາບອດສົມມຸດວ່າທຸກຕົ້ນທາງມີບໍລິການ HTTPS ທີ່ທຽບເທົ່າ.
helper ຕ້ອງຕອບທຸກແຖວຂໍ້ມູນເຂົ້າຕາມໂປຣໂຕຄອນຂອງເວີຊັນ Squid ທີ່ຕິດຕັ້ງ. ຖ້າເປີດໃຊ້ຊ່ອງທາງ helper ພ້ອມກັນ, ຮັກສາຕົວະຊີ້ບອກຊ່ອງທາງໃນຄຳຕອບ. ຕົວຢ່າງ 301:URL ແບບເກົ່າບໍ່ສາມາດແລກກັບຮູບແບບ result-and-key/value ປັດຈຸບັນໄດ້.
ເລືອກການປ່ຽນເສັ້ນທາງຝັ່ງລູກຄ້າເມື່ອ browser ຄວນຮູ້ URL ໃໝ່. ຄຳຕອບ rewrite-url ກັບຂໍໃຫ້ Squid ເອົາ URL ອື່ນຢູ່ຫຼັງຄຳຮ້ອງເດີມຂອງລູກຄ້າ ເຊິ່ງອາດເຮັດໃຫ້ URL ຂອງແອັບ ແລະ ສະຖານະບໍ່ສອດຄ່ອງ.
ຄຳຮ້ອງ HTTP ເບື້ອງຕົ້ນໄດ້ເດີນທາງໄປຫາ Squid ແລ້ວກ່ອນ helper ຈະປ່ຽນເສັ້ນທາງໄດ້. ນະໂຍບາຍນີ້ບໍ່ສາມາດປົກປ້ອງຄຳຮ້ອງນັ້ນຍ້ອນຫຼັງໄດ້. TLS ເລີ່ມຢູ່ການເຊື່ອມຕໍ່ HTTPS ຕໍ່ໄປ; ອຸໂມງ CONNECT ຢ່າງດຽວບໍ່ໃຫ້ການເຂົ້າລະຫັດ.