ການອ່ານການອັບໂຫຼດເປັນສ່ວນໆບໍ່ຕ້ອງການ chunked HTTP

ບໍ່. ໄຄລເອັນສາມາດອ່ານໄຟລ໌ຂະໜາດໃຫຍ່ໃນບັບເຟີນ້ອຍໆ ແລະ ສົ່ງມັນພ້ອມ Content-Length ທີ່ຮູ້. ການອ່ານທີ່ມີຂອບເຂດຄວບຄຸມການໃຊ້ຫນ່ວຍຄວາມຈຳ; ການສ້າງເຟຣມ HTTP ບອກຜູ້ຮັບວ່າຕົວຂໍ້ຄວາມຂອງຄຳຮ້ອງສິ້ນສຸດຢູ່ໃສ.

ໄຟລ໌ທີ່ໝັ້ນຄົງ ເຊິ່ງຄວາມຍາວເປັນໄບຕ໌ທີ່ຫ້ອງສະໝຸດ HTTP ຮູ້ ແຕກຕ່າງຈາກ generator ທີ່ຜະລິດຂໍ້ມູນປະລິມານບໍ່ຮູ້. ໃຊ້ອິນເຕີເຟສຕົວຂໍ້ຄວາມທີ່ຫ້ອງສະໝຸດຮອງຮັບສຳລັບທັງສອງແຫຼ່ງ. ບໍ່ຈຳເປັນຕ້ອງປະກອບໄຟລ໌ທັງໝົດເປັນສະຕຣິງພຽງເພື່ອໃຫ້ຄວາມຍາວ.

ສຳລັບ HTTP/1.1, ກວດເບິ່ງການສ້າງເຟຣມທີ່ສົ່ງຈິງ: Content-Length ຫຼື chunked transfer coding ຕາມກົດຂອງໂປຣໂຕຄອນ. Chunked coding ເພີ່ມເຄື່ອງໝາຍຂະໜາດຢູ່ນອກເນື້ອໃນໄຟລ໌. ຢ່າລວມຊ່ອງຂໍ້ມູນການສ້າງເຟຣມທີ່ຂັດແຍ່ງ ແລະ ຢ່າຄາດເດົາຄວາມຍາວເພື່ອໃຫ້ proxy ຍອມຮັບການອັບໂຫຼດ.

ຖ້າການອັບໂຫຼດຜ່ານ proxy ລົ້ມເຫຼວ, ບັນທຶກເວີຊັນ HTTP, ແຫຼ່ງຕົວຂໍ້ຄວາມ ແລະ ການປະຕິເສດຄັ້ງທຳອິດ. ການຕອບ 411 ຊີ້ໄປຫາການສືບສວນທີ່ແຕກຕ່າງຈາກການເຊື່ອມຕໍ່ທີ່ປິດກາງທາງຕົວຂໍ້ຄວາມ. ຖ້າການລອງການພິສູດຕົວຕົນຄືນລົ້ມເຫຼວແທນ, ກວດເບິ່ງວ່າ ຕົວຂໍ້ຄວາມການອັບໂຫຼດສາມາດຫຼິ້ນຄືນໄດ້ຫຼືບໍ່. ການປ່ຽນຂະໜາດບັບເຟີອ່ານຂອງແອັບພລິເຄຊັນອາດເຮັດໃຫ້ການສ້າງເຟຣມຂອງຄຳຮ້ອງຄືເກົ່າ.

ເສັ້ນທາງມີຄວາມສຳຄັນຕໍ່ການສັງເກດນັ້ນ. ການສົ່ງຂໍ້ຄວາມທຳມະດາເປີດເຜີຍການສ້າງເຟຣມ HTTP ຂອງການອັບໂຫຼດໃຫ້ proxy ເຫັນ; HTTPS ແບບປາຍຕໍ່ປາຍປົກກະຕິໃສ່ມັນໄວ້ໃນອຸໂມງ. HTTP/2 ໃຊ້ການສ້າງເຟຣມຂອງຕົນເອງ. ດັ່ງນັ້ນ ຂໍ້ຈຳກັດທາງປະຫວັດສາດຂອງ Squid ອະທິບາຍຄວາມລົ້ມເຫຼວເກົ່າບາງຢ່າງ, ບໍ່ແມ່ນກົດທີ່ວ່າທຸກ proxy ປັດຈຸບັນປະຕິເສດການອັບໂຫຼດແບບສະຕຣີມ.