د http_proxy بدلون ممکن هېڅ ونه کړي که دمخه د لوړ لومړیتوب gRPC ترتیبات شته وي. لومړی پلي کونه وپېژنئ: لاندې چلند د gRPC C-Core د اصلي HTTP پراکسي میپ او هغو برخو پورې اړه لري چې پر هغه تکیه کوي.

میپ لومړی د چینل پراکسي استدلال، بیا grpc_proxy، بیا https_proxy، بیا http_proxy ګوري او پر لومړي تنظیم شوي ارزښت ودريږي.

د تېښتې موندنه خپل ترتیب لري: no_grpc_proxy پر no_proxy لومړیتوب لري. هلته زوړ ارزښت کولای شي روښانه کړي چې ولې یو هدف له بل ډول تنظیم شوي پراکسي څخه ډډه کوي.

دا میپ HTTP CONNECT کاروي. د هغه مستند شوی پراکسي URI د HTTP سکیم تمه لري؛ د TLS لخوا ساتل شوې gRPC خدمت په خپله د TLS لخوا ساتل شوي پراکسي پای ټکي ته اړتیا نلري. د براوزر د ننوتلو هر ډول سکیم شتون لري داسې مه فرض کوئ، بلکې ملاتړ شوې تصدیق جلا وګورئ. د عامه منځګړو اجازه لرونکي عامه gRPC هدف لپاره، د HTTP پراکسي لېست د ټاکل شوي HTTP پراکسي URI لپاره د پای ټکي نوماندان وړاندې کوي؛ د ریښتیني CONNECT هدف او پورټ ته لاسرسی تایید کړئ.

په Java، Go، JavaScript یا بل ژبه کې د gRPC پلي کونه ممکن بېل ټرانسپورټ کوډ او تنظیم ولري. د C-Core متغیرونو لېست د هر هغه څه لپاره چې gRPC بلل کیږي عمومي قاعده مه جوړوئ.

د ناکام شوي چینل لپاره ټاکل شوی پراکسي، د تېښتې پرېکړه، هدف او د تېروتنې پړاو وساتئ. د بل کلاینټ له لارې د لاسرسي وړ HTTP API دا نه ثابتوي چې دا میپ هغه ورته تنظیمات کارولي یا پراکسي اړین CONNECT منزل اجازه ورکوي.

اړوندې مقالې