ເລືອກ proxy Requests ສຳລັບເວັບໄຊໜຶ່ງ

ເວັບໄຊໜຶ່ງຕ້ອງການ proxy ຕ່າງຈາກຄຳຮ້ອງ HTTPS ອື່ນໆຂອງທ່ານ. Requests ສາມາດສະແດງການເລືອກນັ້ນໃນວັດຈະນານຸກົມ proxy ເອງ:

routes = {
    "https://reports.example": "http://reports-proxy.example:8080",
    "https": "http://default-proxy.example:8080",
}
response = requests.get(
    "https://reports.example/monthly",
    proxies=routes,
    timeout=(5, 20),
)
response.raise_for_status()

ສຳລັບປາຍທາງນັ້ນ ກະແຈສະເພາະ hostname ຈະຊະນະ. hostname HTTPS ອື່ນໃຊ້ລາຍການທົ່ວ scheme. ຄ່າຕ່າງໆອະທິບາຍການເຊື່ອມຕໍ່ proxy ດັ່ງນັ້ນປາຍທາງ HTTPS ສາມາດແມັບໄປຫາ URL proxy HTTP ໄດ້ຢ່າງຖືກຕ້ອງ. ເມື່ອສິ່ງເຫຼົ່ານີ້ເປັນເສັ້ນທາງເວັບໄຊສາທາລະນະທີ່ອະນຸຍາດໂດຍບໍ່ມີບັນຊີ proxy ວັດຈະນານຸກົມ ບັນຊີ proxy HTTP ສາມາດໃຫ້ຜູ້ສະໝັກສຳລັບຄ່າເຫຼົ່ານັ້ນ; ຮັກສາກົດລະບຽບປາຍທາງແຕ່ລະອັນໃຫ້ຊັດເຈນ.

ຈັບຄູ່ hostname ບໍ່ແມ່ນ URL ຊັບພະຍາກອນ

ໃນ Requests 2.32.5 ກະແຈສະເພາະຖືກສ້າງຈາກ scheme ຂອງປາຍທາງ ແລະ hostname ທີ່ແຍກແລ້ວ. ມັນບໍ່ມີເສັ້ນທາງ ຄຳຖາມ ຫຼືພອດ.

ການເພີ່ມ /monthly ໃສ່ກະແຈວັດຈະນານຸກົມຈະບໍ່ຈຳກັດກົດລະບຽບໃຫ້ຢູ່ພຽງເສັ້ນທາງນັ້ນ. ເຊັ່ນດຽວກັນ https://reports.example:8443 ບໍ່ແມ່ນກະແຈສະເພາະພອດທີ່ຕົວເລືອກນີ້ຮູ້ຈັກ. ກົດລະບຽບ hostname ຍັງໃຊ້ເມື່ອ URL ປາຍທາງໃຊ້ພອດອື່ນ.

ບໍ່ມີການຂະຫຍາຍຕົວອັກສອນແທນໃນການຄົ້ນຫານີ້. ກົດລະບຽບສຳລັບ reports.example ບໍ່ກວມເອົາໂດເມນຍ່ອຍໂດຍອັດຕະໂນມັດ. ໃຊ້ການຕັດສິນເສັ້ນທາງທີ່ຊັດເຈນນອກວັດຈະນານຸກົມງ່າຍໆນີ້ ເມື່ອນະໂຍບາຍຕ້ອງການຈັບຄູ່ເສັ້ນທາງ ພອດ ຫຼືຄຳຕໍ່ທ້າຍ.

ຮູ້ວ່າການສຳຮອງໃດມາຕໍ່ໄປ

ການຈັດຕັ້ງປະຕິບັດກວດກະແຈຕາມລຳດັບນີ້: scheme://hostname, scheme, all://hostname ແລ້ວ all. ດັ່ງນັ້ນລາຍການ HTTPS ທົ່ວ scheme ມີບຸລິມະສິດກວ່າລາຍການ hostname ຂອງທຸກ scheme. ໃຫ້ກົດລະບຽບ hostname ສະເພາະ scheme ຢູ່ທຳອິດໃນການອອກແບບຂອງທ່ານ ເມື່ອນັ້ນເປັນຂໍ້ຍົກເວັ້ນທີ່ຕ້ອງການ.

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

ການປ່ຽນເສັ້ນທາງສາມາດນຳ hostname ອື່ນມາ ແລະ ການເລືອກ proxy ກໍກ່ຽວຂ້ອງກັບປາຍທາງໃໝ່ນັ້ນດ້ວຍ. ອ່ານກົດລະບຽບເປັນການຕັດສິນໃຈກ່ຽວກັບແຕ່ລະ URL ທີ່ຖືກຮ້ອງຂໍ ບໍ່ແມ່ນເສັ້ນທາງຖາວອນທີ່ຕິດກັບໜ້າທຳອິດ.