Azure Notification Hubs .NET: איזו הגדרת פרוקסי מנצחת?

הגדירו NotificationHubSettings.Proxy או תעבורת HTTP מסופקת, תוך הכרה בקדימות HttpClient ו-MessageHandler של הבנאי.

ב-API של Notification Hubs .NET עם NotificationHubSettings, אפשר לספק פרוקסי בזמן בניית הלקוח:

var settings = new Microsoft.Azure.NotificationHubs.NotificationHubSettings
{
    Proxy = new System.Net.WebProxy("http://proxy.example:8080")
};
var hub = new Microsoft.Azure.NotificationHubs.NotificationHubClient(
    hubConnectionString, hubName, settings);

מחרוזת החיבור ושם ה-hub נשארים תצורת השירות. נקודת קצה HTTP ציבורית מרשימת פרוקסי HTTP יכולה למלא את כתובת WebProxy במסלול הבנייה המוגדר כברירת מחדל.

יש כלל סדר באותו בנאי:

  1. HttpClient מסופק משמש ראשון.
  2. אחרת, MessageHandler מסופק יוצר את לקוח ה-HTTP.
  3. אחרת, Proxy יוצר HttpClientHandler מוגדר לפרוקסי.
  4. אם לא סופק דבר, הבנאי יוצר את לקוח ה-HTTP המוגדר כברירת מחדל.

אם היישום כבר מספק HttpClient או MessageHandler, הגדירו את הפרוקסי של אותה תעבורה במקום לצפות שמאפיין Proxy הנפרד ידרוס אותו.

עבור חשבון פרוקסי, הגדירו אישורים ב-WebProxy לפני הבנייה. הם מאמתים מול המתווך, לא מול Notification Hub.

דוגמאות ישנות יותר מזכירות NotificationHubClientSettings. התאימו את סוג ההגדרות והבנאי שהחבילה המותקנת חושפת, במקום לערבב את השם הזה ב-API שמצפה ל-NotificationHubSettings.

מאמרים קשורים