כתבו רשומות עקיפה של WebProxy כביטויים רגולריים

הארגומנט BypassList של System.Net.WebProxy מכיל ביטויים רגולריים. תבנית כמו *.office.example אינה תקינה מפני שלכוכבית המובילה אין ביטוי קודם לחזור עליו.

עבור בקשות HTTP ו-HTTPS אל office.example ותת-הדומיינים שלו, תצורת PowerShell יכולה להשתמש ב:

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

הנקודות המוברחות מתאימות לנקודות ממשיות. קבוצת תווית שם המארח החוזרת מתירה גם את הדומיין הבסיסי וגם שמות מתחתיו. העוגנים משאירים שם כמו office.example.other.test מחוץ לכלל הזה. מחרוזות PowerShell במירכאות בודדות משמרות את הקוים הנטויים האחוריים שהביטוי משתמש בהם.

מימוש ה-.NET הנוכחי מתאים ביטויים אלה לסכימה, לשם המארח ולפורט שאינו ברירת מחדל של היעד. הוא אינו כולל את נתיב הבקשה או מחרוזת השאילתה. לכן קבוצת הפורט האופציונלית מתירה גם פורטים שאינם ברירת מחדל; הסירו או צמצמו אותה אם המדיניות דורשת שירות מסוים.

BypassProxyOnLocal הוא false בדוגמה זו כדי שאפשר יהיה לבחון את מדיניות הביטוי הרגולרי בנפרד מהגדרת העקיפה הנוספת הזו. חברו את אובייקט ה-proxy המתקבל ללקוח ה-HTTP שאמור להשתמש בו. לבדיקת כתובת URL ציבורית מותרת מחוץ לדומיין העקיפה, רשומת HTTP מרשימת HTTP proxy list יכולה לספק את כתובתה, בלי חשבון proxy מוגדר.

השתמשו ב-IsBypassed עם ערכי Uri מייצגים כדי לבדוק את החלטת הניתוב: הדומיין הבסיסי, תת-דומיין אחד, מארח חיצוני לא קשור וסיומת ארוכה יותר מטעה. תוצאה true משמעה שנבחרה גישה ישירה; היא אינה מוכיחה שהיעד הישיר נגיש.