ການດາວໂຫຼດ Java ຜ່ານພຣັອກຊີ ເມື່ອ getContentLengthLong ສົ່ງຄືນ -1
ຈັດການ Content-Length ທີ່ບໍ່ຮູ້ຈັກໃນການດາວໂຫຼດ Java ຜ່ານພຣັອກຊີ ໂດຍບໍ່ຖືວ່າເມຕາດາຕາຂະໜາດທີ່ຂາດຫາຍໄປເປັນການຕອບສະໜອງຫວ່າງເປົ່າ.
getContentLengthLong() == -1 ໝາຍຄວາມວ່າບໍ່ມີຄວາມຍາວເນື້ອຫາທີ່ຮູ້ຈັກໃນເມຕາດາຕາທີ່ມີຢູ່. ສືບຕໍ່ອ່ານສະຕຣີມ ແລະ ສະແດງບາຍທີ່ໄດ້ຮັບ ຫຼື ຄວາມຄືບໜ້າທີ່ບໍ່ກຳນົດ; ຢ່າຖືວ່າມັນເປັນການຕອບສະໜອງຫວ່າງເປົ່າ ແລະ ຢ່າຈັດສັນບັຟເຟີຂະໜາດລົບ.
long expected = connection.getContentLengthLong();
long received = 0;
byte[] buffer = new byte[8192];
try (InputStream input = connection.getInputStream()) {
int count;
while ((count = input.read(buffer)) != -1) {
output.write(buffer, 0, count);
received += count;
}
}
ການເຊື່ອມຕໍ່ຖືກຕັ້ງຄ່າແລ້ວ ແລະ output ເປັນຂອງຜູ້ເອີ້ນ. ຮັກສາເວລາກຳນົດການເຊື່ອມຕໍ່ ແລະ ການອ່ານ ພ້ອມທັງຂີດຈຳກັດຂະໜາດໃດໆຂອງແອັບຯອ້ອມຮອບວົງຈອນນີ້. ຄວາມຜິດພາດ I/O ແມ່ນການດາວໂຫຼດທີ່ລົ້ມເຫຼວ ບໍ່ແມ່ນການສຳເລັດດ້ວຍບາຍໜ້ອຍກວ່າ.
ປຽບທຽບຄວາມຍາວໃນຊັ້ນດຽວກັນ. ການເຂົ້າລະຫັດ chunked ຂອງ HTTP/1.1 ສາມາດແທນ Content-Length ແລະ ຖືກຖອດລະຫັດໂດຍການຈັດຕັ້ງ HTTP. ພຣັອກຊີອາດຈັດກອບຄືນໃໝ່. ການຖອດບີບອັດກໍອາດເຮັດໃຫ້ຈຳນວນບາຍທີ່ຖອດລະຫັດຂອງແອັບຯແຕກຕ່າງຈາກ Content-Length ທີ່ເຂົ້າລະຫັດ.
ຖ້າທັງ Transfer-Encoding ແລະ Content-Length ປະກົດຂຶ້ນ, ຢ່າເລືອກຕົວເລກທີ່ສະດວກ: ການຈັດກອບ HTTP ໃຫ້ບຸລິມະສິດແກ່ການເຂົ້າລະຫັດການສົ່ງ ແລະ ຖືວ່າການລວມກັນນັ້ນເປັນຄວາມຜິດພາດທີ່ເປັນໄປໄດ້. ປ່ອຍການແຍກວິເຄາະນັ້ນໃຫ້ການຈັດຕັ້ງທີ່ສອດຄ່ອງ.
URL FTP ຜ່ານເກດເວ HTTP ຕ້ອງການກວດສອບພຶດຕິກຳ URLConnection ທີ່ເປັນຮູບປະທຳຂອງມັນ; ມັນບໍ່ຮັບປະກັນວ່າການເຂົ້າເຖິງຫົວຂໍ້ HTTP ທຸກອັນຈະປະຕິບັດຄືກັບ URL HTTP ປົກກະຕິໃນທຸກ JDK. ໃຊ້ length API ທີ່ມີຄ່າຍາວ ໃນຈຸດທີ່ເມຕາດາຕາສຳຄັນ, ແລະ ກວດສອບສິ່ງທີ່ສຳເລັດແລ້ວທຽບກັບຄວາມຍາວ ຫຼື checksum ທີ່ຕ້ອງການຕົວຈິງ. ການອ່ານຕົວເນື້ອບໍ່ເຮັດໃຫ້ຫົວຂໍ້ທີ່ເຄີຍຂາດຫາຍປະກົດຂຶ້ນ.