ລຳດັບຄວາມສຳຄັນຂອງ proxy ແລະ bypass ໃນ gRPC C-Core
ຕິດຕາມລຳດັບຄວາມສຳຄັນຂອງ proxy ແລະ bypass ຂອງ gRPC Core ໂດຍບໍ່ສົມມຸດວ່າ gRPC ອື່ນໃຊ້ mapper ດຽວກັນ.
ການປ່ຽນ http_proxy ອາດບໍ່ມີຜົນຫຍັງ ເມື່ອມີການຕັ້ງຄ່າ gRPC ທີ່ມີຄວາມສຳຄັນສູງກວ່າຢູ່ແລ້ວ. ເລີ່ມຈາກການລະບຸການຈັດຕັ້ງ: ພຶດຕິກຳຕໍ່ໄປນີ້ເປັນຂອງ mapper HTTP proxy ຄ່າເລີ່ມຕົ້ນຂອງ gRPC C-Core ແລະ ສ່ວນທີ່ຂຶ້ນກັບມັນ.
mapper ກວດກາ argument proxy ຂອງ channel, ຈາກນັ້ນ grpc_proxy, ຈາກນັ້ນ https_proxy, ຈາກນັ້ນ http_proxy ແລະ ຢຸດຢູ່ຄ່າທຳອິດທີ່ຕັ້ງຄ່າໄວ້.
ການຄົ້ນຫາ bypass ມີລຳດັບຂອງມັນເອງ: no_grpc_proxy ມີຄວາມສຳຄັນກວ່າ no_proxy. ຄ່າເກົ່າຢູ່ບ່ອນນັ້ນອາດອະທິບາຍວ່າເປັນຫຍັງເປົ້າໝາຍໜຶ່ງຈຶ່ງຫຼີກລ້ຽງ proxy ທີ່ຕັ້ງຄ່າໄວ້ອີກຢ່າງ.
mapper ນີ້ໃຊ້ HTTP CONNECT. URI proxy ທີ່ບັນທຶກໄວ້ຄາດຫວັງ scheme HTTP; ບໍລິການ gRPC ທີ່ປ້ອງກັນດ້ວຍ TLS ບໍ່ໄດ້ຮຽກຮ້ອງ endpoint proxy ທີ່ປ້ອງກັນດ້ວຍ TLS ໂດຍຕົວມັນເອງ. ກວດກາການພິສູດຢືນຢັນທີ່ຮອງຮັບແຍກຕ່າງຫາກ ແທນທີ່ຈະສົມມຸດວ່າມີ scheme ເຂົ້າສູ່ລະບົບຂອງ browser ໃດໜຶ່ງ. ສຳລັບເປົ້າໝາຍ gRPC ສາທາລະນະທີ່ອະນຸຍາດໃຫ້ມີຕົວກາງສາທາລະນະ, ລາຍການພຣັອກຊີ HTTP ສະເໜີຜູ້ສະໝັກ endpoint ສຳລັບ URI proxy HTTP ທີ່ເລືອກ; ຢືນຢັນການເຂົ້າເຖິງເປົ້າໝາຍ CONNECT ແລະ ພອດຕົວຈິງ.
ການຈັດຕັ້ງ gRPC ໃນ Java, Go, JavaScript ຫຼື ພາສາອື່ນອາດມີໂຄດຂົນສົ່ງ ແລະ ການຕັ້ງຄ່າທີ່ແຕກຕ່າງ. ຢ່າໃຊ້ລາຍການຕົວແປ C-Core ເປັນກົດທົ່ວໄປສຳລັບທຸກຢ່າງທີ່ເອີ້ນວ່າ gRPC.
ສຳລັບ channel ທີ່ລົ້ມເຫຼວ, ເກັບຮັກສາ proxy ທີ່ເລືອກ, ການຕັດສິນ bypass, ເປົ້າໝາຍ ແລະ ຂັ້ນຕອນຄວາມຜິດພາດ. HTTP API ທີ່ເຂົ້າເຖິງໄດ້ຜ່ານ client ອື່ນ ບໍ່ໄດ້ພິສູດວ່າ mapper ນີ້ໃຊ້ການຕັ້ງຄ່າດຽວກັນ ຫຼື proxy ອະນຸຍາດປາຍທາງ CONNECT ທີ່ຕ້ອງການ.