ເມື່ອໄຟລ໌ດາວໂຫຼດເລີ່ມຕົ້ນດ້ວຍແຖວສະຖານະ HTTP

ຖ້າໄຟລ໌ PDF ຫຼື ສະເປຣດຊີດທີ່ຄິດວ່າເປັນເອກະສານ ເລີ່ມຕົ້ນດ້ວຍ HTTP/1.1 200 OK, ຕົວດາວໂຫຼດໄດ້ບັນທຶກຄຳຕອບດິບແທນເອກະສານ. ຄຳຕອບຕົວຢ່າງນີ້ມີເນື້ອຫາພຽງສີ່ໄບຕ໌:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

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

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

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

ຖ້າແອັບພລິເຄຊັນຕ້ອງຮັກສາໂຄ້ດລະດັບ socket ໄວ້, ມັນຕ້ອງຮັບຜິດຊອບກົດການແຍກວິເຄາະທັງໝົດນັ້ນ ພ້ອມທັງການຈັດການການອ່ານແລະການຂຽນ. ຈົ່ງຂຽນພຽງຈຳນວນໄບຕ໌ທີ່ການອ່ານສົ່ງຄືນຈິງ, ບໍ່ແມ່ນຄວາມຈຸຂອງ buffer, ແລະ ຈັດການການຂຽນແບບບາງສ່ວນ. ບໍ່ດັ່ງນັ້ນ ເນື້ອຫາ buffer ທີ່ຄ້າງຢູ່ ສາມາດເຮັດໃຫ້ body ທີ່ສະກັດອອກມາຢ່າງຖືກຕ້ອງເສຍຫາຍໄດ້.

HTTPS ຕ້ອງການຫຼາຍກວ່າການຕັດຄຳຕອບ CONNECT ອອກ: ຫຼັງຈາກຕັ້ງ tunnel ສຳເລັດແລ້ວ, ຕ້ອງສ້າງ TLS ປາຍທາງ ແລ້ວຈຶ່ງແຍກວິເຄາະຄຳຕອບ HTTP ພາຍໃນ. ໄບຕ໌ທີ່ເຂົ້າລະຫັດຕາມຫົວຂໍ້ຂອງພຣັອກຊີ ບໍ່ແມ່ນໄຟລ໌ທີ່ດາວໂຫຼດໄດ້.

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