Proxy- og bypass-variabelprioritet i gRPC C-Core
Følg gRPC Cores proxy- og bypass-prioritet uden at antage, at en anden gRPC-implementering bruger samme mapper.
Ændring af http_proxy kan gøre ingenting, når en gRPC-indstilling med højere prioritet allerede findes. Begynd med at identificere implementeringen: følgende adfærd hører til gRPC C-Cores standard-HTTP-proxymapper og dets afhængigheder.
Mapperen kontrollerer et kanalproxy-argument, derefter grpc_proxy, derefter https_proxy, derefter http_proxy og stopper ved den første konfigurerede værdi.
Bypass-registrering har sin egen rækkefølge: no_grpc_proxy har forrang for no_proxy. En gammel værdi der kan forklare, hvorfor et mål undgår en ellers konfigureret proxy.
Denne mapper bruger HTTP CONNECT. Dens dokumenterede proxy-URI forventer et HTTP-skema; en TLS-beskyttet gRPC-tjeneste kræver ikke i sig selv et TLS-beskyttet proxy-endepunkt. Kontroller understøttet godkendelse separat i stedet for at antage, at en vilkårlig browser-loginordning er tilgængelig. For et offentligt gRPC-mål, hvor offentlige mellemled er tilladt, tilbyder listen over HTTP-proxyer endepunktskandidater til den valgte HTTP-proxy-URI; bekræft adgang til det faktiske CONNECT-mål og den faktiske port.
En Java-, Go-, JavaScript- eller anden gRPC-implementering kan have anden transportkode og konfiguration. Anvend ikke en C-Core-variabelliste som en universel regel for alt, der hedder gRPC.
For en mislykket kanal skal du beholde den valgte proxy, bypass-beslutningen, målet og fejlstadiet. En tilgængelig HTTP-API gennem en anden klient beviser ikke, at denne mapper brugte de samme indstillinger, eller at proxyen tillader det krævede CONNECT-mål.