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 गंतव्य की अनुमति देता है।