NO_PROXY-kompatibilitet på tvers av curl, .NET og containere
Gjør en delt policy for direkte ruting om til klientspesifikk konfigurasjon med et lite sett representative destinasjoner.
Et team legger én omgåelsesstreng i en delt miljøfil. curl går direkte, et annet program bruker proxyen, og en container oppfører seg annerledes igjen. Den delte filen distribuerte de samme tegnene. Den distribuerte ikke én delt parser.
Det varige objektet er policyen: hvilke destinasjoner skal være direkte, under hvilke betingelser? Hold det atskilt fra strengen hvert program trenger.
Skriv de forventede rutene først
Bruk representative adresser, inkludert grensetilfeller og ikke bare enkle suksesser:
| Destinasjonsform | Spørsmål til policyeieren |
|---|---|
| Overordnet domene | Skal det omgås, eller bare barna? |
| Et underdomene | Arver det samme rute? |
| En litterær privat IP | Er den adressen direkte nåbar fra denne klienten? |
| Samme tjeneste under et vertsnavn | Skal navnebaserte og adressebaserte forespørsler stemme overens? |
| En annen tjenesteport | Dekker unntaket verten eller én lytter? |
Identifiser deretter forbrukerne: daemonen som henter et image, programmet inne i containeren, et HTTP-bibliotek for et språk og en interaktiv nettleser kan alle være separate oppføringer. En Docker-klients proxykonfigurasjon kan fylle containerens miljøverdier uten å tvinge hver klient inni til å implementere de samme matchingsreglene.
Oversett i stedet for å kopiere blindt
Ett dokumentert eksempel på en reell forskjell er grensen for overordnet domene. curls domeneunntak dekker det navngitte domenet og samsvarende barn. .NETs miljøpolicy skiller det bare navnet fra underdomenformen med ledende punktum. En universell regel om å „alltid legge til et ledende punktum“ kan ikke uttrykke begge policyene pålitelig.
Støtte for IP-områder avhenger også av forbrukeren og versjonen. En maskin med en ny frittstående curl kan fortsatt kjøre et program som er lenket mot en eldre libcurl, eller en klient som bruker et helt annet bibliotek. Operativsystemutgivelsen er ikke en fullstendig klientoversikt.
For hver forbruker, registrer det støttede konfigurasjonsgrensesnittet og den minste uttrykkelsen av de tiltenkte rutene. En kort eksplisitt vertsliste kan være bedre enn et smart mønster hvis betydning ingen kan forklare.
Hold konfigurasjonsbevis atskilt fra tilkoblingsbevis
En tolket innstilling eller et rutingbeslutnings-API kan vise hva programmet valgte. Et forespørselsutfall viser deretter om ruten var brukbar. I .NET gir HttpClient.DefaultProxy.IsBypassed den konfigurasjonssidige kontrollen når standardproxyen er policyen som brukes. Ikke diagnostiser en utilgjengelig direkte tjeneste som en omgåelsesparserfeil bare fordi forespørselen fikk tidsavbrudd.
Behold grensedestinasjonene når du oppdaterer en klient eller et basisimage. De gjør fremtidige kompatibilitetsendringer synlige uten at hele teamet må gjenoppdage hvorfor filen inneholder to liknende domeneoppføringer.