أولوية متغيرات الوكيل والتجاوز في gRPC C-Core

قد لا يُحدث تغيير http_proxy أي أثر عندما يكون إعداد gRPC ذو الأولوية الأعلى موجودًا بالفعل. ابدأ بتحديد التطبيق: السلوك التالي يخص مُخطِّط HTTP الوكيل الافتراضي في gRPC C-Core وتوابعه.

يفحص المُخطِّط وسيط الوكيل الخاص بالقناة، ثم grpc_proxy، ثم https_proxy، ثم http_proxy، ويتوقف عند أول قيمة مضبوطة.

لاكتشاف التجاوز ترتيبه الخاص: no_grpc_proxy له أسبقية على no_proxy. وقد تفسّر قيمة قديمة هناك سبب تجنّب هدفٍ ما لوكيلٍ مضبوط في غير ذلك.

يستخدم هذا المُخطِّط HTTP CONNECT. عنوان URI الموثّق للوكيل يتوقع مخطط HTTP؛ فخدمة gRPC المحمية بـ TLS لا تتطلب بذاتها نقطة نهاية وكيل محمية بـ TLS. افحص المصادقة المدعومة على حدة بدل افتراض توفر أي مخطط تسجيل دخول خاص بالمتصفح. وبالنسبة إلى هدف gRPC عام يُسمح فيه بالوسطاء العامين، تقدّم قائمة وكلاء HTTP مرشّحي نقاط نهاية لعنوان URI المختار للوكيل؛ تحقّق من الوصول إلى هدف CONNECT والمنفذ الفعليين.

قد يكون لتطبيق gRPC بلغة Java أو Go أو JavaScript أو غيرها شيفرة نقل وإعدادات مختلفة. لا تُطبّق قائمة متغيرات C-Core كقاعدة شاملة على كل ما يُسمّى gRPC.

عند فشل قناة، احتفظ بالوكيل المختار وقرار التجاوز والهدف ومرحلة الخطأ. إن الوصول إلى واجهة HTTP برمجية عبر عميل آخر لا يثبت أن هذا المُخطِّط استخدم الإعدادات نفسها أو أن الوكيل يسمح بوجهة CONNECT المطلوبة.