ແຖວໃໝ່ເພີ່ມອີກໜຶ່ງແຖວອາດເຮັດໃຫ້ TLS ເສຍຫາຍຫຼັງ CONNECT

ເມື່ອ CONNECT ຕອບກັບ 200 ແລະ TLS ຖອດລະຫັດບໍ່ໄດ້ທັນທີ, ກວດເບິ່ງໄບຕ໌ຂອບເຂດໃນຕົວເຊື່ອມຕໍ່ ກ່ອນທີ່ຈະປ່ຽນໃບຢັ້ງຢືນ ຫຼື ຊິບເຟີ.

ຄ່າອະນຸຍາດທີ່ສ້າງຂຶ້ນອາດຈົບລົງດ້ວຍແຖວໃໝ່ແລ້ວ. ການເພີ່ມຈຸດສິ້ນສຸດແຖວອີກອັນໜຶ່ງອາດເຮັດໃຫ້ຫົວ HTTP ຈົບກ່ອນເວລາ, ເຮັດໃຫ້ຊ່ອງ Host ທີ່ຕັ້ງໃຈ ຫຼື ຂໍ້ຄວາມທຳມະດາອື່ນໆຄ້າງຢູ່ຫຼັງຄຳຮ້ອງຂໍ.

ຄຳຮ້ອງຂໍ HTTP/1.1 CONNECT ຂັ້ນຕ່ຳໃຊ້ CRLF ລະຫວ່າງແຖວ ແລະ ແຖວຫວ່າງທີ່ທ້າຍ:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

ໃສ່ຊ່ອງອະນຸຍາດໃດໆກ່ອນແຖວຫວ່າງສຸດທ້າຍນັ້ນ, ໂດຍບໍ່ມີການຕັດແຖວຝັງຢູ່ພາຍໃນ. ໃນ Python, "\n" ໝາຍເຖິງແຖວໃໝ່; ສະຕຣິງດິບທີ່ມີ backslash ແລະ ຕົວອັກສອນ n ບໍ່ໝາຍເຖິງ. ກວດເບິ່ງວ່າຕົວຊ່ວຍການເຂົ້າລະຫັດສ້າງໄບຕ໌ໃດ ກ່ອນທີ່ຈະພະຍາຍາມລຶບມັນອອກ—ຕົວຊ່ວຍເກົ່າອາດເພີ່ມການຕັດແຖວ.

ເມື່ອ CONNECT ສຳເລັດ, ໄບຕ໌ທີ່ເຫຼືອເຫຼົ່ານັ້ນເປັນຂອງໂປຣໂຕຄໍອຸໂມງ. ຂໍ້ຄວາມທຳມະດາທີ່ຫຼົງທາງອາດໄປຮອດຄູ່ທີ່ຄາດຫວັງ TLS. ສະຖານະສຳເລັດບໍ່ສາມາດສ້ອມໄບຕ໌ທີ່ຢູ່ໃນຄິວແລ້ວຫຼັງຄຳຮ້ອງຂໍທີ່ຜິດຮູບແບບ.

ກວດເບິ່ງຂອບເຂດການຮັບດ້ວຍ. ອ່ານການຕອບກັບຂອງພຣັອກຊີໃຫ້ຄົບ ກ່ອນມອບຊອກເກັດໃຫ້ TLS, ຈັດການການອ່ານແບບບາງສ່ວນ ແລະ ຮັກສາທຸກຢ່າງທີ່ອ່ານເກີນຫົວ. ການອ່ານຊອກເກັດຄັ້ງດຽວບໍ່ຈຳເປັນຕ້ອງມີຂໍ້ຄວາມໜຶ່ງເຕັມ.

ຖ້າທ່ານເປັນເຈົ້າຂອງຕົວແຍກນີ້, ສົມທຽບການນຳສະເໜີໄບຕ໌ທີ່ປັບແລ້ວກັບໄວຍາກອນສາຍ; ເກັບຄວາມຍາວ ແລະ ຂອບເຂດແຖວໃຫ້ເຫັນ ໃນຂະນະທີ່ເຊື່ອງລະຫັດຜ່ານ. ສຳລັບແອັບທີ່ຕ້ອງການພຽງການເຊື່ອມຕໍ່ພຣັອກຊີ, ຕົວເຊື່ອມຕໍ່ທີ່ຖືກບຳລຸງຮັກສາຫຼີກລ້ຽງການເປັນເຈົ້າຂອງໂຄດກອບນີ້.