gRPC C-Core میں پراکسی اور بائی پاس متغیرات کی ترجیح

اگر پہلے سے زیادہ ترجیح والی gRPC سیٹنگ موجود ہو تو http_proxy بدلنے سے کچھ نہیں ہو سکتا۔ پہلے نفاذ کی شناخت کریں: درج ذیل رویہ 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 نفاذ کا ٹرانسپورٹ کوڈ اور تشکیل مختلف ہو سکتی ہے۔ gRPC کہلانے والی ہر چیز پر C-Core متغیرات کی فہرست کو عالمگیر قاعدہ کے طور پر نہ لگائیں۔

ناکام چینل کے لیے منتخب پراکسی، بائی پاس فیصلہ، ہدف اور خرابی کا مرحلہ محفوظ رکھیں۔ کسی دوسرے کلائنٹ کے ذریعے قابل رسائی HTTP API یہ ثابت نہیں کرتا کہ اس میپر نے وہی سیٹنگز استعمال کیں یا پراکسی مطلوبہ CONNECT منزل کی اجازت دیتی ہے۔