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 ગંતવ્યને મંજૂરી આપે છે.