ຮ່າງ POST ຂອງ Python HTTP proxy ສາມາດຖືກ buffer ໃນ rfile
ອ່ານຄຳຮ້ອງຂໍ Python HTTP proxy ຜ່ານອິນພຸດທີ່ຖືກ buffer ຂອງ handler ແທນທີ່ຈະລໍຖ້າ byte ທີ່ອອກຈາກ buffer socket ແລ້ວ.
Forward proxy ອ່ານແຖວຄຳຮ້ອງຂໍ ແລະ ຫົວຂໍ້, ສົ່ງຕໍ່ພວກມັນ, ແລ້ວລໍຖ້າໃນ select ສຳລັບຮ່າງ POST. ລູກຄ້າໄດ້ສົ່ງມັນແລ້ວ. ທັງສອງຝ່າຍເບິ່ງຄືກັບລໍຖ້າກັນແລະກັນ.
ກັບ BaseHTTPRequestHandler ຂອງ Python, ການອ່ານຫົວຂໍ້ຜ່ານ rfile, ເຊິ່ງເປັນ stream ອິນພຸດທີ່ຖືກ buffer. stream ນັ້ນສາມາດອ່ານລ່ວງໜ້າ ແລະ ຖື byte ທີ່ເປັນຂອງຮ່າງ. ການລໍຖ້າເທິງ socket ຂ້າງລຸ່ມພຽງແຕ່ຖາມວ່າ file descriptor ຂອງມັນພ້ອມແລ້ວຫຼືບໍ່; ມັນບໍ່ໄດ້ຖາມວ່າ Python stream ມີຂໍ້ມູນທີ່ໃຊ້ໄດ້ແລ້ວຫຼືບໍ່.
ຕິດຕາມ buffer ທີ່ອ່ານຫົວຂໍ້
ອ່ານຮ່າງຜ່ານ self.rfile ເຊັ່ນກັນ. ຢ່າປ່ຽນໄປ self.connection.recv ຫຼັງຈາກແຍກຫົວຂໍ້ດ້ວຍ stream ທີ່ຖືກ buffer. ບໍ່ດັ່ງນັ້ນໂຄດອາດຂ້າມ byte ທີ່ stream ນັ້ນຖືຢູ່ ແລະ ລໍຖ້າຂໍ້ມູນທີ່ຈະບໍ່ຖືກສົ່ງອີກ.
ການສົ່ງ rfile ເອງໄປ select ບໍ່ເຮັດໃຫ້ select ກວດ buffer Python ຂອງມັນ. API ຄວາມພ້ອມເຮັດວຽກຜ່ານ file descriptor ຂອງວັດຖຸ.
ສຳລັບຄຳຮ້ອງຂໍທີ່ມີ Content-Length ທີ່ຖືກຕ້ອງໜຶ່ງ ແລະ ບໍ່ມີ Transfer-Encoding, ໃຊ້ຈຳນວນ byte ທີ່ປະກາດໄວ້ຢ່າງແທ້ຈິງ, ຈັດການການສິ້ນສຸດຂອງອິນພຸດກ່ອນເວລາ ແລະ ຂີດຈຳກັດຂະໜາດ ແລະ ເວລາຂອງທ່ານ. ຢ່າອ່ານຈົນຮອດ EOF: ລູກຄ້າທີ່ໃຊ້ການເຊື່ອມຕໍ່ແບບຕໍ່ເນື່ອງອາດປະການເຊື່ອມຕໍ່ໄວ້ເປີດຫຼັງຈາກສຳເລັດຄຳຮ້ອງຂໍ.
ເຮັດໃຫ້ການກອບເປັນສ່ວນທີ່ຊັດເຈນຂອງ proxy
ຮ່າງຄຳຮ້ອງຂໍແບບ chunked ຕ້ອງການການສະໜັບສະໜູນການກອບແບບ chunked. ພວກມັນບໍ່ສາມາດຖືກອ່ານໂດຍການຊອກຫາ Content-Length ທີ່ບໍ່ມີ. metadata ຄວາມຍາວທີ່ກຳກວມຕ້ອງການເສັ້ນທາງປະຕິເສດທີ່ກຳນົດໄວ້, ແທນທີ່ຈະເລືອກຫົວຂໍ້ທີ່ເບິ່ງຄືສະດວກ.
handler ແບບ blocking ສາມາດສືບຕໍ່ໃຊ້ອິນເຕີເຟສ stream ຂອງມັນກັບການອ່ານທີ່ມີຂີດຈຳກັດ. proxy ທີ່ຂັບເຄື່ອນດ້ວຍເຫດການຕ້ອງການຮູບແບບ buffer ທີ່ລວມການອ່ານລ່ວງໜ້າຂອງ parser ກັບການຈັດການຄວາມພ້ອມ. ການປ່ຽນ timeout ຈະບໍ່ປອງດອງຜູ້ບໍລິໂພກສອງຄົນທີ່ເປັນເອກະລາດຂອງ socket ດຽວກັນ.
ການບົ່ງມະຕິນີ້ເຈາະຈົງກັບບ່ອນທີ່ byte ຂາເຂົ້າຖືກຖືໄວ້. ເມື່ອ proxy ໄດ້ໃຊ້ຮ່າງທີ່ຖືກຕ້ອງແລ້ວ, ມັນຍັງຕ້ອງສົ່ງຕໍ່ຮ່າງນັ້ນດ້ວຍການກອບ HTTP ທີ່ສອດຄ່ອງ. handler http.server ມາດຕະຖານເປັນສະຖານທີ່ທີ່ເປັນປະໂຫຍດໃນການເຂົ້າໃຈກົນໄກ, ແຕ່ມັນບໍ່ແມ່ນການຈັດຕັ້ງ proxy ສົ່ງຕໍ່ສຳລັບການຜະລິດ.