NO_PROXY-versoenbaarheid tussen curl, .NET en houers
Skakel 'n gedeelde direkte-roetering-beleid om in kliëntspesifieke konfigurasie met 'n klein stel verteenwoordigende bestemmings.
'n Span plaas een omseilstring in 'n gedeelde omgewingslêer. curl gaan direk, 'n ander toepassing gebruik die proxy, en 'n houer tree weer anders op. Die gedeelde lêer het dieselfde karakters versprei. Dit het nie een gedeelde ontleder versprei nie.
Die blywende objek is die beleid: watter bestemmings moet direk wees, onder watter voorwaardes? Hou dit apart van die string wat elke program nodig het.
Skryf eers die verwagte roetes neer
Gebruik verteenwoordigende adresse, insluitend grense eerder as net maklike suksesse:
| Bestemmingsvorm | Vraag vir die beleideienaar |
|---|---|
| Ouerdomein | Moet dit omseil word, of net sy kinders? |
| 'n Subdomein | Erf dit dieselfde roete? |
| 'n Letterlike private IP | Is daardie adres direk vanaf hierdie kliënt bereikbaar? |
| Dieselfde diens onder 'n gasheernaam | Moet naamgebaseerde en adresgebaseerde versoeke ooreenstem? |
| 'n Ander dienspoort | Dek die uitsondering die gasheer of een luisteraar? |
Identifiseer dan die verbruikers: die daemon wat 'n beeld trek, die program binne die houer, 'n taal-HTTP-biblioteek en 'n interaktiewe blaaier kan almal aparte inskrywings wees. 'n Docker-kliënt-proxykonfigurasie kan houeromgewingswaardes vul sonder dat elke kliënt binne dieselfde passingsreëls moet implementeer.
Vertaal eerder as om blindelings te kopieer
Een gedokumenteerde voorbeeld van 'n werklike verskil is die ouerdomeingrens. curl se domeinuitsluiting dek die genoemde domein en passende kinders. .NET se omgewingsbeleid onderskei die kaal naam van die voorpunt-subdomeinvorm. 'n Universele reël om altyd 'n voorpunt by te voeg kan nie beide beleide betroubaar uitdruk nie.
IP-reeksondersteuning hang ook af van die verbruiker en sy weergawe. 'n Masjien met 'n nuwe selfstandige curl kan steeds 'n toepassing laat loop wat aan 'n ouer libcurl gekoppel is, of 'n kliënt wat heeltemal 'n ander biblioteek gebruik. Die bedryfstelselvrystelling is nie 'n volledige kliëntinventaris nie.
Teken vir elke verbruiker sy ondersteunde konfigurasiekoppelvlak en die kleinste uitdrukking van die beoogde roetes aan. 'n Kort eksplisiete gasheellys kan beter wees as 'n slim patroon waarvan niemand die betekenis kan verduidelik nie.
Hou konfigurasiebewyse apart van verbindingsbewyse
'n Ontlede instelling of roeteringbesluit-API kan wys wat die program gekies het. 'n Versoekuitkoms wys dan of daardie roete bruikbaar was. In .NET, HttpClient.DefaultProxy.IsBypassed verskaf daardie konfigurasiekant-kontrole wanneer die verstekproxy die beleid in gebruik is. Moenie 'n onbereikbare direkte diens as 'n omseil-ontlederfout diagnoseer net omdat die versoek se tyd verstryk het nie.
Behou die grensbestemmings wanneer jy 'n kliënt of 'n basisbeeld opdateer. Hulle maak toekomstige versoenbaarheidsveranderinge sigbaar sonder dat die hele span weer moet ontdek waarom die lêer twee eenders lykende domeininskrywings bevat.