Proxy e precedencia de variables de omisión en gRPC C-Core
Segue a precedencia de proxy e omisión de gRPC Core sen supoñer que outra implementación de gRPC usa o mesmo asignador.
Cambiar http_proxy pode non facer nada se xa existe un axuste de gRPC con maior prioridade. Comeza identificando a implementación: o comportamento seguinte pertence ao asignador HTTP de proxy predeterminado de gRPC C-Core e aos seus dependentes.
O asignador comproba un argumento de proxy de canle, logo grpc_proxy, logo https_proxy, logo http_proxy, e detense no primeiro valor configurado.
O descubrimento de omisións ten a súa propia orde: no_grpc_proxy ten precedencia sobre no_proxy. Un valor antigo alí pode explicar por que un destino evita un proxy configurado doutro xeito.
Este asignador usa HTTP CONNECT. O seu URI de proxy documentado espera un esquema HTTP; un servizo gRPC protexido con TLS non require por si mesmo un extremo de proxy protexido con TLS. Comproba a autenticación admitida por separado en vez de supoñer que está dispoñible calquera esquema de inicio de sesión do navegador. Para un destino gRPC público onde se permiten intermediarios públicos, a lista de proxys HTTP ofrece candidatos de extremo para o URI de proxy HTTP seleccionado; confirma o acceso ao destino e porto reais de CONNECT.
Unha implementación de gRPC en Java, Go, JavaScript ou outra linguaxe pode ter código de transporte e configuración distintos. Non apliques unha lista de variables de C-Core como regra universal a todo o que se chama gRPC.
Para unha canle fallida, conserva o proxy seleccionado, a decisión de omisión, o destino e a etapa do erro. Unha API HTTP accesible desde outro cliente non demostra que este asignador usase os mesmos axustes nin que o proxy permita o destino CONNECT requirido.