NO_PROXY-kongrueco en curl, .NET kaj ujoj
Turnu komunan rektan enkursigan politikon en klient-specifan agordon per malgranda aro da reprezentaj celoj.
Teamo metas unu preterpasan ĉenon en komunan medipan dosieron. curl iras rekte, alia aplikaĵo uzas la prokurilon, kaj ujo kondutas denove alie. La komuna dosiero disdonis la samajn signojn. Sed ĝi ne disdonis unu komunan analizilon.
La daŭra objekto estas la politiko: kiuj celoj estu rektaj, sub kiuj kondiĉoj? Tenu tion aparte de la ĉeno, kiun ĉiu programo bezonas.
Unue skribu la atendatajn vojojn
Uzu reprezentajn adresojn, inkluzive de limoj kaj ne nur facilaj sukcesoj:
| Formo de la celo | Demando al la posedanto de la politiko |
|---|---|
| Patra domajno | Ĉu preterpasi ĝin, aŭ nur ĝiajn infanojn? |
| Subdomajno | Ĉu ĝi heredas la saman vojon? |
| Literala privata IP | Ĉu tiu adreso estas rekte atingebla de ĉi tiu kliento? |
| La sama servo sub gastiga nomo | Ĉu nom-bazitaj kaj adres-bazitaj petoj konsentu? |
| Alia serva pordo | Ĉu la escepto kovras la gastiganton aŭ unu aŭskultanton? |
Poste identigu la konsumantojn: la demono, kiu tiras bildon, la programo ene de la ujo, lingva HTTP-biblioteko kaj interaga retumilo povas ĉiuj esti apartaj eroj. Docker-klienta prokura agordo povas plenigi ujajn medivalorojn sen ke ĉiu kliento interne devas efektivigi la samajn kongruajn regulojn.
Traduku anstataŭ blinda kopiado
Unu dokumentita ekzemplo de reala diferenco estas la limo de la patra domajno. La domajna ekskludo de curl kovras la nomatan domajnon kaj kongruajn infanojn. La media politiko de .NET distingas la nudan nomon disde la subdomajna formo kun konduka punkto. Universala regulo ĉiam aldoni kondukan punkton ne povas fidinde esprimi ambaŭ politikojn.
Subteno de IP-gamoj ankaŭ dependas de la konsumanto kaj ĝia versio. Maŝino kun nova memstara curl ankoraŭ povas ruli aplikaĵon ligitan al pli malnova libcurl, aŭ klienton uzantan tute alian bibliotekon. La eldono de la operaciumo ne estas kompleta klienta inventaro.
Por ĉiu konsumanto, registru ĝian subtenatan agordan interfacon kaj la plej malgrandan esprimon de la celataj vojoj. Mallonga eksplicita gastiglista listo povas esti pli bona ol ruza ŝablono, kies signifon neniu povas klarigi.
Tenu agordajn pruvojn aparte de konektaj pruvoj
Analizita agordo aŭ enkursiga-decida API povas montri, kion la programo elektis. Peto-rezulto poste montras, ĉu tiu vojo estis uzebla. En .NET, HttpClient.DefaultProxy.IsBypassed provizas tiun agordan flankkontrolon, kiam la defaŭlta prokurilo estas la uzata politiko. Ne diagnozu neatingeblan rektan servon kiel malsukceson de la preterpasa analizilo nur ĉar la peto tempolimis.
Konservu la limajn celojn kiam vi ĝisdatigas klienton aŭ bazan bildon. Ili igas estontajn kongruecajn ŝanĝojn videblaj sen postuli, ke la tuta teamo denove malkovru, kial la dosiero enhavas du similspecajn domajnajn erojn.