ເປັນຫຍັງ APT ຈຶ່ງບໍ່ໃຊ້ CONNECT ສຳລັບທຸກການດາວໂຫຼດ
ການສົ່ງຕໍ່ HTTP ທຳມະດາ ແລະ ອຸໂມງ HTTPS ໃຊ້ການສົນທະນາກັບພຣັອກຊີທີ່ແຕກຕ່າງກັນ. ບໍລິການທີ່ຮອງຮັບພຽງ CONNECT ອາດຈະບໍ່ຮອງຮັບຄຳຮ້ອງທີ່ຄັງ HTTP ສ້າງຂຶ້ນ.
“ພຣັອກຊີຮັບ CONNECT” ບໍ່ໄດ້ໝາຍຄວາມວ່າມັນຮັບທຸກຄຳຮ້ອງທີ່ APT ຈະສົ່ງ.
ສຳລັບຄັງ HTTP ທຳມະດາ, APT ສາມາດໃຊ້ການສົ່ງຕໍ່ຜ່ານພຣັອກຊີ HTTP ປົກກະຕິ: ພຣັອກຊີໄດ້ຮັບຄຳຮ້ອງ HTTP ທີ່ລະບຸຊັບພະຍາກອນປາຍທາງ. ສຳລັບ HTTPS ຜ່ານພຣັອກຊີ HTTP, ລູກຄ້າໂດຍປົກກະຕິສ້າງອຸໂມງ CONNECT, ແລ້ວເຈລະຈາເຊສຊັນ TLS ຂອງປາຍທາງຜ່ານອຸໂມງນັ້ນ.
| ປາຍທາງ | ການສົນທະນາປົກກະຕິກັບພຣັອກຊີ HTTP |
|---|---|
| ຄັງ HTTP | ສົ່ງຕໍ່ຄຳຮ້ອງ HTTP |
| ຄັງ HTTPS | CONNECT, ແລ້ວ TLS ປາຍທາງ |
ບໍລິການທີ່ຮັບພຽງອຸໂມງອາດປະຕິເສດຄຳຮ້ອງທີ່ສົ່ງຕໍ່ປົກກະຕິ. HTTP 405 ຄວນໄດ້ຮັບການກວດເບິ່ງວິທີຕົວຈິງ, ຜູ້ອອກການຕອບສະໜອງ ແລະ ນະໂຍບາຍພຣັອກຊີ; ມັນບໍ່ໄດ້ພິສູດວ່າ APT ບໍ່ມີການຮອງຮັບ SOCKS ຫຼື ລະຫັດຜ່ານຂອງມັນຜິດ.
ປຽບທຽບພຶດຕິກຳທີ່ຮອງຮັບຂອງບໍລິການກັບເອກະສານການຂົນສົ່ງຂອງ APT ແລະ ຄວາມໝາຍຂອງ CONNECT. ໃຊ້ບໍລິການທີ່ໄດ້ຮັບອະນຸມັດທີ່ເຂົ້າກັນໄດ້ ຫຼື URL ຄັງທີ່ຮອງຮັບ. ສຳລັບຄັງສາທາລະນະທີ່ອະນຸຍາດໃຫ້ມີຕົວກາງສາທາລະນະ, ລາຍຊື່ພຣັອກຊີ HTTP ສະເໜີຜູ້ສະໝັກເພື່ອກວດສອບຕາມຂໍ້ກຳນົດເຫຼົ່ານັ້ນ. ຢ່າສົມມຸດວ່າການເພີ່ມ https:// ໃສ່ທີ່ຢູ່ພຣັອກຊີປ່ຽນໂປຣໂຕຄອນຂອງຄັງ ຫຼື ເຮັດໃຫ້ທຸກຄຳຮ້ອງກາຍເປັນອຸໂມງ.