ຮັກສາຂໍ້ມູນທີ່ຢູ່ໃນບັຟເຟີຫຼັງການຕອບສະໜອງ HTTP CONNECT

ຕົວຫຸ້ມພຣັອກຊີນ້ອຍໆສາມາດເຮັດວຽກກັບ HTTPS ແລ້ວຄ້າງໄດ້ເມື່ອນຳກັບມາໃຊ້ກັບໂປຣໂຕຄອນທີ່ເຊີບເວີຂອງມັນເວົ້າກ່ອນ. ແຖວທີ່ໜ້າສົງໄສມັກຈະເປັນແຖວທີ່ລໍຖ້າໃຫ້ບັຟເຟີຮັບຂໍ້ມູນ ສິ້ນສຸດ ດ້ວຍ \r\n\r\n.

TCP ໃຫ້ກະແສຂໍ້ມູນແກ່ລູກຄ້າ. ການເອີ້ນຮັບຂໍ້ມູນຄັ້ງດຽວອາດສົ່ງຄືນເຄິ່ງແຖວສະຖານະ HTTP, ການຕອບສະໜອງ CONNECT ທັງໝົດ, ຫຼື ການຕອບສະໜອງນັ້ນຕາມດ້ວຍຂໍ້ມູນອຸໂມງທັນທີ. ບໍ່ມີການຮັບປະກັນວ່າການອ່ານຈະຢຸດທີ່ທ້າຍສ່ວນຫົວ.

ຊອກຫາຂອບເຂດພາຍໃນບັຟເຟີ

ສຳລັບການແລກປ່ຽນ HTTP/1.1 CONNECT, ໃຫ້ສະສົມໄບຈົນກວ່າຕົວໝາຍສິ້ນສຸດສ່ວນຫົວຈະປະກົດຢູ່ບ່ອນໃດກໍໄດ້ໃນບັຟເຟີ. ແຍກທີ່ຈຸດປະກົດຄັ້ງທຳອິດ. ວິເຄາະແຖວສະຖານະ ແລະ ສ່ວນຫົວຈາກພາກທຳອິດ; ເກັບທຸກຢ່າງຫຼັງຈາກຂອບເຂດໄວ້ແຍກຕ່າງຫາກ. ໃຊ້ຂີດຈຳກັດຂະໜາດສ່ວນຫົວ ແລະ ເວລາຈຳກັດເວລາລໍຖ້າ, ແລະ ຖືວ່າການອ່ານຊ໋ອກເກັດຫວ່າງເປັນການເຊື່ອມຕໍ່ທີ່ປິດແລ້ວ ບໍ່ແມ່ນການເຊີນໃຫ້ວົນຊ້ຳອີກ.

ການຕອບສະໜອງ 2xx ສຸດທ້າຍທີ່ສຳເລັດຈະປ່ຽນການເຊື່ອມຕໍ່ເປັນໂໝດອຸໂມງທັນທີຫຼັງຈາກສ່ວນຫົວເຫຼົ່ານັ້ນ. ໄບທີ່ຕາມມາຫຼັງມັນເປັນໄບຂອງອຸໂມງແລ້ວ. ຢ່າຖິ້ມພວກມັນ, ຢ່າ ລໍຖ້າເນື້ອຄວາມຂອງການຕອບສະໜອງ CONNECT, ແລະ ຢ່າຕີຄວາມເຂົ້າໃຈຊ່ອງ Content-Length ວ່າເປັນການອະນຸຍາດໃຫ້ໃຊ້ສ່ວນໜຶ່ງຂອງໂປຣໂຕຄອນໃໝ່. ການຕອບສະໜອງແບບຂໍ້ມູນ ຖ້າມີ ຕ້ອງຖືກຈັດການກ່ອນການຕອບສະໜອງສຸດທ້າຍນັ້ນ.

ຕົວຫຸ້ມຕ້ອງສົ່ງຕໍ່ສິ່ງທີ່ເຫຼືອຂອງມັນ

ການສົ່ງຄືນພຽງຊ໋ອກເກັດພື້ນຖານຈະເຮັດໃຫ້ເສຍໄບໃດໆທີ່ຕົວແຍກການຈັບມືໄດ້ດຶງອອກຈາກມັນແລ້ວ. ຜູ້ອ່ານຄົນຕໍ່ໄປຕ້ອງການກະແສທີ່ມີບັຟເຟີ ເຊິ່ງໃຫ້ຫາງທີ່ເກັບໄວ້ກ່ອນ ແລ້ວຈຶ່ງສືບຕໍ່ການອ່ານຊ໋ອກເກັດ. ສຳລັບໂປຣໂຕຄອນທີ່ເຊີບເວີເວົ້າກ່ອນ, ການເສຍຄຳທັກທຳອິດນັ້ນອາດເຮັດໃຫ້ທັງສອງຝ່າຍລໍຖ້າຢ່າງບໍ່ມີທີ່ສິ້ນສຸດ.

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

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