Proxy- und Bypass-Variablenpriorität in gRPC C-Core
Verfolgen Sie die Proxy- und Bypass-Priorität von gRPC Core, ohne anzunehmen, dass eine andere gRPC-Implementierung denselben Mapper verwendet.
Das Ändern von http_proxy kann wirkungslos bleiben, wenn bereits eine gRPC-Einstellung mit höherer Priorität vorhanden ist. Beginnen Sie mit der Identifizierung der Implementierung: Das folgende Verhalten gehört zum standardmäßigen HTTP-Proxy-Mapper von gRPC C-Core und seinen abhängigen Komponenten.
Der Mapper prüft ein Kanal-Proxy-Argument, dann grpc_proxy, dann https_proxy, dann http_proxy und stoppt beim ersten konfigurierten Wert.
Die Bypass-Erkennung hat ihre eigene Reihenfolge: no_grpc_proxy hat Vorrang vor no_proxy. Ein alter Wert dort kann erklären, warum ein Ziel einen ansonsten konfigurierten Proxy umgeht.
Dieser Mapper verwendet HTTP CONNECT. Seine dokumentierte Proxy-URI erwartet ein HTTP-Schema; ein TLS-geschützter gRPC-Dienst erfordert nicht von sich aus einen TLS-geschützten Proxy-Endpunkt. Prüfen Sie unterstützte Authentifizierung separat, statt anzunehmen, dass irgendein Browser-Anmeldeschema verfügbar ist. Für ein öffentliches gRPC-Ziel, bei dem öffentliche Vermittler zulässig sind, bietet die HTTP-Proxy-Liste Endpunktkandidaten für die gewählte HTTP-Proxy-URI; bestätigen Sie den Zugriff auf das tatsächliche CONNECT-Ziel und den Port.
Eine gRPC-Implementierung in Java, Go, JavaScript oder einer anderen Sprache kann anderen Transportcode und andere Konfiguration haben. Wenden Sie eine C-Core-Variablenliste nicht als allgemeine Regel auf alles an, was gRPC heißt.
Bei einem fehlgeschlagenen Kanal behalten Sie den gewählten Proxy, die Bypass-Entscheidung, das Ziel und die Fehlerstufe. Eine über einen anderen Client erreichbare HTTP-API belegt nicht, dass dieser Mapper dieselben Einstellungen verwendet hat oder dass der Proxy das erforderliche CONNECT-Ziel zulässt.