ການຢຸດຊົ່ວຄາວຂອງການອັບໂຫຼດ HTTP ແລະ Expect: 100-continue

ຮັບຮູ້ການແລກປ່ຽນ Expect: 100-continue ແລະ ແຍກຈຸດຕັດສິນໃຈສັ້ນໆຂອງມັນອອກຈາກການອັບໂຫຼດທີ່ຕິດຄ້າງລະຫວ່າງການສົ່ງຂໍ້ມູນ.

ການເຊື່ອມຕໍ່ເປີດຂຶ້ນ. ຫົວຂໍ້ຄຳຮ້ອງຖືກສົ່ງອອກໄປ. ເບິ່ງຄືວ່າໄຟລ໌ບໍ່ເຄື່ອນ. ຄຳອະທິບາຍໜຶ່ງແມ່ນວ່າ ລູກຄ້າກຳລັງລໍຖ້າການຕອບສະໜອງຕໍ່ Expect: 100-continue ກ່ອນທີ່ຈະສົ່ງເນື້ອຫາຂອງມັນ.

ກົນໄກນີ້ເຮັດໃຫ້ຜູ້ຮັບສາມາດປະຕິເສດຄຳຮ້ອງຈາກຫົວຂໍ້ຂອງມັນ ກ່ອນທີ່ການອັບໂຫຼດທີ່ອາດຈະໃຫຍ່ຈະຖືກສົ່ງໄປ. ລຳດັບຄວາມສຳເລັດປົກກະຕິແມ່ນ:

request headers → 100 Continue → request body → final response

100 ເປັນຂໍ້ມູນແຈ້ງເຕືອນ: ມັນອະນຸຍາດໃຫ້ລູກຄ້າສືບຕໍ່ ແຕ່ບໍ່ໄດ້ໝາຍຄວາມວ່າໄຟລ໌ຖືກເກັບໄວ້ ຫຼື ການດຳເນີນງານຂອງແອັບພລິເຄຊັນສຳເລັດແລ້ວ. ການ push ຂອງ Git ທີ່ຕອບກັບ HTTP 417 ແມ່ນກໍລະນີຄວາມລົ້ມເຫຼວຂອງຄວາມຄາດຫວັງທີ່ເປັນຮູບປະທຳໜຶ່ງ.

ຊອກຫາວ່າລູກຄ້າໄດ້ຮັບການຕອບສະໜອງໃດ

ສິ່ງທີ່ສັງເກດເຫັນຄວາມໝາຍທີ່ຕ້ອງສືບສວນ
100 Continueລູກຄ້າສາມາດສືບຕໍ່ກັບເນື້ອຫາໄດ້
ການປະຕິເສດຂັ້ນສຸດທ້າຍກ່ອນເນື້ອຫາການດຳເນີນງານຖືກປະຕິເສດໃນຂັ້ນຕອນຫົວຂໍ້
ບໍ່ມີການຕອບສະໜອງຊົ່ວຄາວຕາມທີ່ຄາດຫວັງນະໂຍບາຍການລໍຖ້າຂອງລູກຄ້າ ແລະ ການຈັດການໃນເສັ້ນທາງນັ້ນ

curl ມີການຕັ້ງຄ່າການລໍຖ້າ expect-continue ແຍກຕ່າງຫາກ. ຖ້າການລໍຖ້າຂອງ libcurl ນັ້ນໝົດເວລາໂດຍບໍ່ມີການຕອບສະໜອງຕາມທີ່ຄາດຫວັງ, ມັນຈະສົ່ງເນື້ອຫາໄປຢ່າງໃດກໍຕາມ; ການໝົດເວລາບໍ່ໄດ້ໝາຍຄວາມວ່າການໂອນທັງໝົດລົ້ມເຫຼວໂດຍອັດຕະໂນມັດ. ການຕັ້ງຄ່ານີ້ແຍກອອກຈາກເວລາທີ່ອະນຸຍາດສຳລັບການໂອນທັງໝົດ. ການເພີ່ມເວລາຫຼັງອາດເຮັດໃຫ້ການຢຸດຊົ່ວຄາວເບື້ອງຕົ້ນຄືເກົ່າຍັງບໍ່ຖືກອະທິບາຍ.

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

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

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ