Proxy- og bypass-variabelprioritet i gRPC C-Core
Følg gRPC Cores proxy- og bypass-prioritet uten å anta at en annen gRPC-implementasjon bruker samme mapper.
Å endre http_proxy kan gjøre ingenting når en gRPC-innstilling med høyere prioritet allerede finnes. Begynn med å identifisere implementasjonen: følgende atferd tilhører gRPC C-Cores standard HTTP-proxymapper og det som avhenger av den.
Mapperen kontrollerer et kanalproxy-argument, deretter grpc_proxy, deretter https_proxy, deretter http_proxy, og stopper ved den første konfigurerte verdien.
Bypass-oppdagelse har sin egen rekkefølge: no_grpc_proxy har forrang foran no_proxy. En gammel verdi der kan forklare hvorfor et mål unngår en ellers konfigurert proxy.
Denne mapperen bruker HTTP CONNECT. Den dokumenterte proxy-URI-en forventer et HTTP-skjema; en TLS-beskyttet gRPC-tjeneste krever ikke i seg selv et TLS-beskyttet proxy-endepunkt. Kontroller støttet autentisering separat i stedet for å anta at en vilkårlig nettleserinnlogging er tilgjengelig. For et offentlig gRPC-mål der offentlige mellomledd er tillatt, tilbyr listen over HTTP-proxyer endepunktkandidater for den valgte HTTP-proxy-URI-en; bekreft tilgang til det faktiske CONNECT-målet og porten.
En Java-, Go-, JavaScript- eller annen gRPC-implementasjon kan ha annen transportkode og konfigurasjon. Ikke bruk en C-Core-variabelliste som en universell regel for alt som kalles gRPC.
For en mislykket kanal, behold den valgte proxyen, bypass-avgjørelsen, målet og feiltrinnet. Et HTTP-API som nås via en annen klient beviser ikke at denne mapperen brukte de samme innstillingene, eller at proxyen tillater det nødvendige CONNECT-målet.