Prioritet for proxy- og bypass-variablar i gRPC C-Core
Følg proxy- og bypass-prioriteten til gRPC Core utan å anta at ein annan gRPC-implementasjon brukar same mappar.
Å endre http_proxy kan gjere ingenting når ein gRPC-innstilling med høgare prioritet alt finst. Byrja med å identifisere implementasjonen: den følgjande åtferda høyrer til standard HTTP-proxymappar i gRPC C-Core og det som er avhengig av han.
Mapparen kontrollerer eit kanalproxy-argument, deretter grpc_proxy, deretter https_proxy, deretter http_proxy, og stoppar ved den første konfigurerte verdien.
Bypass-oppdaging har sin eigen rekkjefølgje: no_grpc_proxy går føre no_proxy. Ein gammal verdi der kan forklare kvifor eit mål unngår ein elles konfigurert proxy.
Denne mapparen brukar HTTP CONNECT. Den dokumenterte proxy-URI-en ventar eit HTTP-skjema; ei TLS-beskytta gRPC-teneste krev ikkje i seg sjølv eit TLS-beskytta proxy-endepunkt. Kontroller støtta autentisering separat i staden for å anta at ei vilkårleg nettlesarinnlogging er tilgjengeleg. For eit offentleg gRPC-mål der offentlege mellomledd er tillatne, tilbyr lista over HTTP-proxyar endepunktkandidatar for den valde HTTP-proxy-URI-en; stadfest tilgang til det faktiske CONNECT-målet og porten.
Ein Java-, Go-, JavaScript- eller annan gRPC-implementasjon kan ha annan transportkode og konfigurasjon. Ikkje bruk ei C-Core-variabelliste som ei universell regel for alt som heiter gRPC.
For ein mislukka kanal, hald på den valde proxyen, bypass-avgjerda, målet og feiltrinnet. Eit HTTP-API som ein annan klient kan nå, beviser ikkje at denne mapparen brukte dei same innstillingane, eller at proxyen tillèt det nødvendige CONNECT-målet.