NO_PROXY-kompatibilitet mellan curl, .NET och containrar
Gör en delad policy för direkt dirigerning till klientspecifik konfiguration med en liten uppsättning representativa mål.
Ett team lägger en enda kringgående sträng i en delad miljöfil. curl går direkt, ett annat program använder proxyn och en container beter sig annorlunda igen. Den delade filen distribuerade samma tecken. Den distribuerade inte en delad parser.
Det varaktiga objektet är policyn: vilka mål ska vara direkta och under vilka villkor? Håll det åtskilt från strängen som varje program behöver.
Skriv de förväntade rutterna först
Använd representativa adresser, inklusive gränsfall och inte bara enkla framgångar:
| Målets form | Fråga till policyägaren |
|---|---|
| Överordnad domän | Ska den kringgås, eller bara dess underdomäner? |
| En underdomän | Ärver den samma rutt? |
| En literal privat IP | Är den adressen direkt nåbar från den här klienten? |
| Samma tjänst under ett värdnamn | Ska namnbaserade och adressbaserade förfrågningar stämma överens? |
| En annan tjänsteport | Täcker undantaget värden eller en enda lyssnare? |
Identifiera sedan konsumenterna: daemonen som hämtar en avbildning, programmet inuti containern, ett HTTP-bibliotek för ett språk och en interaktiv webbläsare kan alla vara separata poster. En Docker-klients proxykonfiguration kan fylla containerns miljövärden utan att tvinga varje klient inuti att implementera samma matchningsregler.
Översätt i stället för att kopiera blint
Ett dokumenterat exempel på en verklig skillnad är gränsen för överordnad domän. curls domänundantag omfattar den namngivna domänen och matchande underdomäner. .NET:s miljöpolicy skiljer det bara namnet från underdomänformen med inledande punkt. En universell regel att „alltid lägga till en inledande punkt“ kan inte uttrycka båda policyerna tillförlitligt.
Stöd för IP-intervall beror också på konsumenten och dess version. En maskin med en ny fristående curl kan fortfarande köra ett program som är länkat mot en äldre libcurl, eller en klient som använder ett helt annat bibliotek. Operativsystemets utgåva är inte en fullständig klientförteckning.
För varje konsument, registrera det stödda konfigurationsgränssnittet och det minsta uttrycket för de avsedda rutterna. En kort explicit värdlista kan vara bättre än ett smart mönster vars betydelse ingen kan förklara.
Håll konfigurationsbevis åtskilt från anslutningsbevis
En tolkad inställning eller ett API för routingbeslut kan visa vad programmet valde. En förfrågans utfall visar sedan om rutten var användbar. I .NET ger HttpClient.DefaultProxy.IsBypassed den kontrollen på konfigurationssidan när standardproxyn är policyn som används. Diagnostisera inte en onåbar direkt tjänst som ett fel i kringgångsparsern bara för att förfrågan fick timeout.
Behåll gränsmålen när du uppdaterar en klient eller en basavbildning. De gör framtida kompatibilitetsändringar synliga utan att hela teamet måste upptäcka på nytt varför filen innehåller två liknande domänposter.