Priorità delle variabili proxy e bypass in gRPC C-Core
Seguite la priorità di proxy e bypass di gRPC Core senza presumere che un'altra implementazione gRPC usi lo stesso mapper.
Modificare http_proxy può non fare nulla se esiste già un'impostazione gRPC con priorità più alta. Iniziate identificando l'implementazione: il comportamento seguente appartiene al mapper HTTP proxy predefinito di gRPC C-Core e ai suoi dipendenti.
Il mapper controlla un argomento proxy di canale, poi grpc_proxy, poi https_proxy, poi http_proxy, e si ferma al primo valore configurato.
Il rilevamento del bypass ha un proprio ordine: no_grpc_proxy ha la precedenza su no_proxy. Un vecchio valore lì può spiegare perché una destinazione evita un proxy altrimenti configurato.
Questo mapper usa HTTP CONNECT. Il suo URI proxy documentato prevede uno schema HTTP; un servizio gRPC protetto con TLS non richiede di per sé un endpoint proxy protetto con TLS. Verificate separatamente l'autenticazione supportata invece di presumere che sia disponibile qualsiasi schema di accesso del browser. Per una destinazione gRPC pubblica in cui sono ammessi intermediari pubblici, la lista dei proxy HTTP offre candidati endpoint per l'URI proxy HTTP scelto; confermate l'accesso alla destinazione CONNECT e alla porta effettive.
Un'implementazione gRPC in Java, Go, JavaScript o altro può avere codice di trasporto e configurazione diversi. Non applicate un elenco di variabili C-Core come regola universale a tutto ciò che si chiama gRPC.
Per un canale non riuscito, conservate il proxy selezionato, la decisione di bypass, la destinazione e la fase di errore. Un'API HTTP raggiungibile tramite un altro client non dimostra che questo mapper abbia usato le stesse impostazioni né che il proxy consenta la destinazione CONNECT richiesta.