Pierwszeństwo zmiennych proxy i obejścia w gRPC C-Core
Prześledź pierwszeństwo proxy i obejścia w gRPC Core, nie zakładając, że inna implementacja gRPC używa tego samego mappera.
Zmiana http_proxy może nic nie dać, jeśli istnieje już ustawienie gRPC o wyższym priorytecie. Zacznij od zidentyfikowania implementacji: poniższe zachowanie należy do domyślnego mappera HTTP proxy gRPC C-Core i jego zależności.
Mapper sprawdza argument proxy kanału, potem grpc_proxy, potem https_proxy, potem http_proxy i zatrzymuje się na pierwszej skonfigurowanej wartości.
Wykrywanie obejścia ma własną kolejność: no_grpc_proxy ma pierwszeństwo przed no_proxy. Stara wartość w tym miejscu może wyjaśnić, dlaczego jeden cel omija skądinąd skonfigurowane proxy.
Ten mapper używa HTTP CONNECT. Jego udokumentowany URI proxy oczekuje schematu HTTP; usługa gRPC chroniona przez TLS sama z siebie nie wymaga punktu końcowego proxy chronionego przez TLS. Sprawdzaj obsługiwane uwierzytelnianie osobno, zamiast zakładać, że dostępny jest dowolny schemat logowania przeglądarki. Dla publicznego celu gRPC, w którym dozwolone są publiczne pośredniki, listy proxy HTTP oferuje kandydatów punktów końcowych dla wybranego URI proxy HTTP; potwierdź dostęp do rzeczywistego celu i portu CONNECT.
Implementacja gRPC w Javie, Go, JavaScripcie lub innym języku może mieć inny kod transportu i konfigurację. Nie stosuj listy zmiennych C-Core jako uniwersalnej reguły do wszystkiego, co nazywa się gRPC.
Dla nieudanego kanału zachowaj wybrane proxy, decyzję o obejściu, cel i etap błędu. HTTP API osiągalne przez innego klienta nie dowodzi, że ten mapper użył tych samych ustawień ani że proxy dopuszcza wymagany cel CONNECT.