NO_PROXY-Kompatibilität bei curl, .NET und Containern
Verwandeln Sie eine gemeinsame Direkt-Routing-Richtlinie mit einer kleinen Menge repräsentativer Ziele in klientspezifische Konfiguration.
Ein Team legt eine Bypass-Zeichenkette in eine gemeinsame Umgebungsdatei. curl geht direkt, eine andere Anwendung nutzt den Proxy, und ein Container verhält sich wieder anders. Die gemeinsame Datei verteilte dieselben Zeichen. Sie verteilte aber keinen gemeinsamen Parser.
Das dauerhafte Objekt ist die Richtlinie: Welche Ziele sollen direkt sein, unter welchen Bedingungen? Halten Sie sie getrennt von der Zeichenkette, die jedes Programm benötigt.
Schreiben Sie zuerst die erwarteten Routen auf
Verwenden Sie repräsentative Adressen, einschließlich Grenzfällen statt nur einfacher Erfolge:
| Form des Ziels | Frage an den Richtlinienverantwortlichen |
|---|---|
| Übergeordnete Domain | Soll sie umgangen werden oder nur ihre Unterdomains? |
| Eine Subdomain | Erbt sie dieselbe Route? |
| Eine literale private IP | Ist diese Adresse von diesem Client aus direkt erreichbar? |
| Derselbe Dienst unter einem Hostnamen | Sollen namensbasierte und adressbasierte Anfragen übereinstimmen? |
| Ein anderer Dienstport | Deckt die Ausnahme den Host oder einen Listener ab? |
Identifizieren Sie dann die Verbraucher: Der Daemon, der ein Image zieht, das Programm im Container, eine HTTP-Bibliothek einer Sprache und ein interaktiver Browser können alle separate Einträge sein. Eine Docker-Client-Proxykonfiguration kann Containerumgebungswerte füllen, ohne dass jeder Client im Inneren dieselben Abgleichsregeln implementieren muss.
Übersetzen statt blind kopieren
Ein dokumentiertes Beispiel für einen echten Unterschied ist die Grenze der übergeordneten Domain. Der Domainausschluss von curl deckt die benannte Domain und passende Unterdomains ab. Die Umgebungsrichtlinie von .NET unterscheidet den bloßen Namen von der Subdomain-Form mit führendem Punkt. Eine universelle Regel, immer einen führenden Punkt hinzuzufügen, kann beide Richtlinien nicht zuverlässig ausdrücken.
Die Unterstützung von IP-Bereichen hängt ebenfalls vom Verbraucher und seiner Version ab. Ein Rechner mit einem neuen eigenständigen curl kann weiterhin eine Anwendung ausführen, die mit einem älteren libcurl verlinkt ist, oder einen Client, der eine ganz andere Bibliothek verwendet. Die Betriebssystemversion ist kein vollständiges Client-Inventar.
Notieren Sie für jeden Verbraucher seine unterstützte Konfigurationsschnittstelle und den kleinsten Ausdruck der beabsichtigten Routen. Eine kurze explizite Hostliste kann besser sein als ein cleveres Muster, dessen Bedeutung niemand erklären kann.
Halten Sie Konfigurationsnachweise getrennt von Verbindungsnachweisen
Eine geparste Einstellung oder eine Routing-Entscheidungs-API kann zeigen, was das Programm ausgewählt hat. Ein Anfrageergebnis zeigt dann, ob diese Route nutzbar war. In .NET, HttpClient.DefaultProxy.IsBypassed liefert diese konfigurationsseitige Prüfung, wenn der Standardproxy die verwendete Richtlinie ist. Diagnostizieren Sie einen nicht erreichbaren direkten Dienst nicht allein deshalb als Bypass-Parser-Fehler, weil die Anfrage zeitlich abgelaufen ist.
Behalten Sie die Grenzziele beim Aktualisieren eines Clients oder eines Basisimages bei. Sie machen künftige Kompatibilitätsänderungen sichtbar, ohne dass das ganze Team neu entdecken muss, warum die Datei zwei ähnlich aussehende Domaineinträge enthält.