L'argument BypassList de System.Net.WebProxy contient des expressions régulières. Un motif comme *.office.example est invalide car l'astérisque initial n'a pas d'expression précédente à répéter.

Pour les requêtes HTTP et HTTPS vers office.example et ses sous-domaines, une configuration PowerShell peut utiliser :

$bypass = @('^https?://([a-z0-9-]+\.)*office\.example(:[0-9]+)?$')
$proxy = [System.Net.WebProxy]::new(
    'http://proxy.example:8080',
    $false,
    [string[]]$bypass
)

Les points échappés correspondent à des points littéraux. Le groupe répété d'étiquette de nom d'hôte admet à la fois le domaine de base et les noms situés en dessous. Les ancres maintiennent un nom comme office.example.other.test hors de cette règle. Les chaînes PowerShell entre guillemets simples conservent les barres obliques inverses utilisées par l'expression.

L'implémentation .NET actuelle compare ces expressions au schéma, au nom d'hôte et au port non standard de la destination. Elle n'inclut ni le chemin de la requête ni la chaîne de requête. Le groupe de port facultatif autorise donc aussi les ports non standard ; supprimez-le ou restreignez-le si la politique exige un service précis.

BypassProxyOnLocal vaut false dans cet exemple afin que la politique d'expression régulière puisse être examinée séparément de ce réglage d'exception supplémentaire. Attachez l'objet proxy obtenu au client HTTP qui doit l'utiliser. Pour un test d'URL publique autorisé hors du domaine d'exception, une entrée HTTP de la HTTP proxy list peut fournir son adresse, sans compte proxy configuré.

Utilisez IsBypassed avec des valeurs Uri représentatives pour examiner la décision de routage : le domaine de base, un sous-domaine, un hôte externe sans rapport et un suffixe plus long trompeur. Un résultat true signifie que l'accès direct a été choisi ; il ne prouve pas que la destination directe est joignable.

Articles similaires