Proxy- és bypass-változók elsőbbsége a gRPC C-Core-ban
Kövesse a gRPC Core proxy- és bypass-elsőbbségét anélkül, hogy feltételezné, egy másik gRPC-implementáció ugyanazt a mappert használja.
A http_proxy módosítása semmit sem tehet, ha már van egy magasabb elsőbbségű gRPC-beállítás. Kezdje az implementáció azonosításával: a következő viselkedés a gRPC C-Core alapértelmezett HTTP-proxy mapperéhez és a rá épülő elemekhez tartozik.
A mapper először a csatorna proxy argumentumát, majd a grpc_proxy, majd a https_proxy, majd a http_proxy változót ellenőrzi, és az első beállított értéknél megáll.
A bypass felderítésének saját sorrendje van: a no_grpc_proxy elsőbbséget élvez a no_proxy változóval szemben. Egy ottani régi érték megmagyarázhatja, miért kerül el egy cél egy egyébként beállított proxyt.
Ez a mapper HTTP CONNECTet használ. A dokumentált proxy URI HTTP-sémát vár; a TLS-sel védett gRPC-szolgáltatás önmagában nem igényel TLS-sel védett proxy végpontot. A támogatott hitelesítést külön ellenőrizze, ahelyett hogy feltételezné, bármely böngészős bejelentkezési séma elérhető. Nyilvános gRPC-cél esetén, ahol nyilvános közvetítők engedélyezettek, a HTTP-proxyk listájából végpontjelölteket kínál a kiválasztott HTTP-proxy URI-hoz; erősítse meg a tényleges CONNECT-cél és -port elérését.
Egy Java, Go, JavaScript vagy más nyelvű gRPC-implementáció eltérő átviteli kóddal és konfigurációval rendelkezhet. Ne alkalmazza a C-Core változólistát általános szabályként mindenre, amit gRPC-nek neveznek.
Sikertelen csatorna esetén őrizze meg a kiválasztott proxyt, a bypass-döntést, a célt és a hiba szakaszát. Egy másik kliensen keresztül elérhető HTTP API nem bizonyítja, hogy ez a mapper ugyanazokat a beállításokat használta, vagy hogy a proxy engedélyezi a szükséges CONNECT-célt.