Domaines parents et sous-domaines dans .NET NO_PROXY
Incluez délibérément le domaine parent lorsqu'une stratégie de proxy d'environnement .NET doit aussi contourner ses sous-domaines.
Dans les règles de proxy d'environnement documentées de .NET, .example.com correspond aux sous-domaines. Il ne correspond pas à example.com lui-même. Cette petite distinction peut scinder un service entre deux routes.
| Entrée | Correspondance .NET prévue |
|---|---|
example.com | Le nom d'hôte parent |
.example.com | Noms d'hôte sous ce domaine |
example.com,.example.com | Les deux groupes |
Supposons que la page d'accueil utilise le nom parent et que son API utilise api.example.com. Une liste ne contenant que la forme pointée peut faire passer la page d'accueil par le proxy tandis que l'API passe en direct. L'erreur inverse consiste à ne lister que le domaine parent et à attendre que chaque enfant corresponde. Inspectez HttpClient.DefaultProxy.IsBypassed pour le domaine parent et un enfant afin de vérifier la décision configurée.
Cela s'applique à la stratégie d'environnement utilisée par le client HTTP .NET participant. Un IWebProxy assigné explicitement, une autre implémentation de gestionnaire ou une autre génération d'exécution doit faire vérifier ses propres règles. Ne supposez pas que la liste de contournement d'un navigateur soit devenue cette liste d'environnement.
Résistez aussi à l'habitude de traduire le paramètre en *.example.com. La syntaxe d'environnement .NET documentée ne traite pas l'astérisque comme un joker général.
Lorsque vous comparez une commande curl fonctionnelle avec l'application, conservez l'URL littérale dans le rapport. “Même serveur” masque si vous avez demandé le domaine parent, un sous-domaine ou une adresse IP. La correspondance de domaine s'effectue sur cette entrée de requête, pas sur votre nom informel du service.