ສົ່ງຕໍ່ໄບຕ໌ gzip ພ້ອມກັບຫົວຂໍ້ທີ່ອະທິບາຍພວກມັນ
ເລືອກ payload ທີ່ເຂົ້າລະຫັດ ຫຼື ຖອດລະຫັດໃນ proxy ທີ່ອີງໃສ່ Requests, ແລ້ວໃຫ້ການຕອບສະໜອງທາງລຸ່ມມີ content headers ທີ່ກົງກັນ ແລະ framing ຂອງຕົວມັນເອງ.
ຖ້າ Requests ໄດ້ຂະຫຍາຍຕົວຂໍ້ຄວາມແລ້ວ, ການສົ່ງຕໍ່ມັນດ້ວຍ Content-Encoding: gzip ຮຽກຮ້ອງໃຫ້ລູກຄ້າຕໍ່ໄປຂະຫຍາຍມັນອີກຄັ້ງ. ຕັດສິນໃຈວ່າ proxy ສົ່ງຕົວແທນ payload ໃດກ່ອນທີ່ຈະຄັດລອກຫົວຂໍ້ຂອງມັນ.
| Payload ທີ່ສົ່ງ | content headers |
|---|---|
| ໄບຕ໌ທີ່ເຂົ້າລະຫັດເດີມ | ຮັກສາການເຂົ້າລະຫັດທີ່ໃຊ້ໄດ້ ແລະ ຄວາມຍາວ payload ທີ່ແນ່ນອນ |
| ໄບຕ໌ທີ່ຖອດລະຫັດ | ລຶບການເຂົ້າລະຫັດທີ່ຖອດແລ້ວ; ລຶບ ຫຼື ຄິດໄລ່ຄວາມຍາວທີ່ກົງກັນຄືນໃໝ່ |
ສຳລັບໄບຕ໌ payload ທີ່ເຂົ້າລະຫັດ, ສ່ວນນີ້ອ່ານສະຕຣີມດິບຂອງ urllib3 ໂດຍບໍ່ມີການຖອດລະຫັດ content:
with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
upstream.raise_for_status()
for block in upstream.raw.stream(65536, decode_content=False):
downstream.write(block)downstream ແມ່ນຜົນຜະລິດການຕອບສະໜອງທີ່ມີຢູ່ແລ້ວ. ສະຖານະ ແລະ ຫົວຂໍ້ຂອງມັນຕ້ອງປະຕິບັດຕາມນະໂຍບາຍທີ່ເລືອກແລ້ວ; ສ່ວນນີ້ບໍ່ໄດ້ຈັດຕັ້ງເຊີບເວີ proxy ທີ່ສົມບູນ.
Framing ການສົ່ງຕໍ່ແຍກຈາກການເຂົ້າລະຫັດ content gzip. ຫ້ອງສະໝຸດ HTTP ທາງເທິງໄດ້ຈັດການ framing ແລ້ວ, ລວມທັງການລຶບ chunk, ດັ່ງນັ້ນຢ່າຄັດລອກ Transfer-Encoding ແບບປິດຕາ. ເຊີບເວີທາງລຸ່ມສ້າງ framing ຂອງການຕອບສະໜອງຕົວເອງ ເຖິງແມ່ນວ່າ payload ຍັງເຂົ້າລະຫັດດ້ວຍ gzip.
response.text ຕາມດ້ວຍການເຂົ້າລະຫັດ UTF-8 ກໍ່ປ່ຽນຕົວແທນ ແລະ ບໍ່ສາມາດຮັກສາຂໍ້ມູນໄບນາຣີຕາມອຳເພີໄດ້. ປິດ ຫຼື ໃຊ້ການຕອບສະໜອງທາງເທິງໃນທຸກເສັ້ນທາງ, ແລະ ຈັດການຂໍ້ຜິດພາດ HTTP ຕາມສັນຍາ proxy: ຕົວຢ່າງນີ້ໂຍນພວກມັນແທນທີ່ຈະສົ່ງຕໍ່.