NO_PROXY-yhteensopivuus curlissa, .NETissä ja konttoreissa
Muunna jaettu suoran reitityksen käytäntö asiakaskohtaiseksi kokoonpanoksi käyttämällä pientä joukkoa edustavia kohteita.
Tiimi laittaa yhden ohitusmerkkijonon jaettuun ympäristötiedostoon. curl menee suoraan, toinen sovellus käyttää välityspalvelinta ja kontti käyttäytyy taas eri tavalla. Jaettu tiedosto jakoi samat merkit. Mutta se ei jakanut yhtä yhteistä jäsennintä.
Kestävä objekti on käytäntö: mitkä kohteet pitäisi olla suoria ja millä ehdoilla? Pidä se erillään merkkijonosta, jonka kukin ohjelma tarvitsee.
Kirjoita odotetut reitit ensin
Käytä edustavia osoitteita, mukaan lukien rajat eikä vain helppoja onnistumisia:
| Kohteen muoto | Kysymys käytännön omistajalle |
|---|---|
| Ylätason verkkotunnus | Pitäisikö ohittaa se vai vain sen aliverkkotunnukset? |
| Aliverkkotunnus | Periikö se saman reitin? |
| Kirjaimellinen yksityinen IP | Onko tämä osoite suoraan tavoitettavissa tästä asiakkaasta? |
| Sama palvelu isäntänimen alla | Pitäisikö nimipohjaisten ja osoitepohjaisten pyyntöjen täsmätä? |
| Toinen palveluportti | Kattaako poikkeus isännän vai yhden kuuntelijan? |
Tunnista sitten kuluttajat: imagen hakeva taustaprosessi, kontin sisällä oleva ohjelma, kielen HTTP-kirjasto ja vuorovaikutteinen selain voivat kaikki olla erillisiä merkintöjä. Docker-asiakkaan välityspalvelinkokoonpano voi täyttää kontin ympäristöarvot ilman, että jokaisen sisällä olevan asiakkaan täytyy toteuttaa samat vastaavuussäännöt.
Käännä sen sijaan, että kopioit sokeasti
Yksi dokumentoitu esimerkki todellisesta erosta on ylätason verkkotunnuksen raja. curlin verkkotunnuksen poissulkeminen kattaa nimetyn verkkotunnuksen ja vastaavat aliverkkotunnukset. .NETin ympäristökäytäntö erottaa paljaan nimen etupisteellisestä aliverkkotunnusmuodosta. Yleinen sääntö lisää aina etupiste ei voi ilmaista molempia käytäntöjä luotettavasti.
IP-alueiden tuki riippuu myös kuluttajasta ja sen versiosta. Kone, jossa on uusi itsenäinen curl, voi silti ajaa sovellusta, joka on linkitetty vanhempaan libcurliin, tai asiakasta, joka käyttää täysin toista kirjastoa. Käyttöjärjestelmän julkaisu ei ole täydellinen asiakasluettelo.
Kirjaa kullekin kuluttajalle sen tuettu kokoonpanorajapinta ja pienin ilmaus aiotuista reiteistä. Lyhyt selkeä isäntäluettelo voi olla parempi kuin ovela kuvio, jonka merkitystä kukaan ei osaa selittää.
Pidä kokoonpanon todisteet erillään yhteyden todisteista
Jäsennetty asetus tai reitityspäätösten API voi näyttää, mitä ohjelma valitsi. Pyynnön tulos näyttää sitten, oliko reitti käyttökelpoinen. .NETissä, HttpClient.DefaultProxy.IsBypassed tarjoaa tämän kokoonpanopuolen tarkistuksen, kun oletusvälityspalvelin on käytössä oleva käytäntö. Älä diagnosoi tavoittamatonta suoraa palvelua ohitusjäsentimen viaksi vain siksi, että pyyntö aikakatkaistiin.
Säilytä rajakohteet, kun päivität asiakasta tai perusimagoa. Ne tekevät tulevat yhteensopivuusmuutokset näkyviksi ilman, että koko tiimin täytyy löytää uudelleen, miksi tiedosto sisältää kaksi samannäköistä verkkotunnusmerkintää.