gRPC C-Core-proxy en voorkeurorde van omseil-veranderlikes
Volg gRPC Core se proxy- en omseilvoorkeurorde sonder om te aanvaar dat 'n ander gRPC-implementering dieselfde mappeerder gebruik.
Om http_proxy te verander kan niks doen as 'n hoërprioriteit-gRPC-instelling reeds teenwoordig is. Begin deur die implementering te identifiseer: die volgende gedrag hoort by gRPC C-Core se verstek-HTTP-proxymapper en sy afhanklikes.
Die mappeerder kyk na 'n kanaalproxy-argument, dan grpc_proxy, dan https_proxy, dan http_proxy, en stop by die eerste ingestelde waarde.
Omseilontdekking het sy eie orde: no_grpc_proxy het voorkeur bo no_proxy. 'n Ou waarde daar kan verduidelik waarom een teiken 'n andersins ingestelde proxy vermy.
Hierdie mappeerder gebruik HTTP CONNECT. Sy gedokumenteerde proxy-URI verwag 'n HTTP-skema; 'n TLS-beskermde gRPC-diens vereis nie op sigself 'n TLS-beskermde proxy-eindpunt nie. Kontroleer ondersteunde verifikasie afsonderlik eerder as om te aanvaar dat enige blaaier-aanmeldingstelsel beskikbaar is. Vir 'n publieke gRPC-teiken waar publieke tussengangers toegelaat word, bied die HTTP-instaanbedienerlys eindpuntkandidate vir die gekose HTTP-proxy-URI; bevestig toegang tot die werklike CONNECT-teiken en -poort.
'n Java-, Go-, JavaScript- of ander gRPC-implementering kan ander vervoerkode en -konfigurasie hê. Moenie 'n C-Core-veranderlikelys as 'n universele reël vir alles wat gRPC heet toepas nie.
Vir 'n mislukte kanaal, behou die gekose proxy, die omseilbesluit, die teiken en die foutstadium. 'n Bereikbare HTTP-API deur 'n ander kliënt bewys nie dat hierdie mappeerder dieselfde instellings gebruik het of dat die proxy die vereiste CONNECT-bestemming toelaat nie.