Azure Notification Hubs .NET: które ustawienie serwera proxy wygrywa?

Skonfiguruj NotificationHubSettings.Proxy lub dostarczony transport HTTP, uwzględniając pierwszeństwo HttpClient i MessageHandler w konstruktorze.

W interfejsie Notification Hubs .NET API z NotificationHubSettings serwer proxy można podać podczas tworzenia klienta:

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);

Parametry połączenia i nazwa centrum pozostają konfiguracją usługi. Publiczny punkt końcowy HTTP z lista serwerów proxy HTTP może wypełnić adres WebProxy w domyślnej ścieżce tworzenia.

W tym konstruktorze obowiązuje reguła kolejności:

  1. Najpierw używany jest dostarczony HttpClient.
  2. W przeciwnym razie dostarczony MessageHandler tworzy klienta HTTP.
  3. W przeciwnym razie Proxy tworzy HttpClientHandler skonfigurowany dla serwera proxy.
  4. Jeśli nic nie dostarczono, konstruktor tworzy swój domyślny klient HTTP.

Jeśli aplikacja już dostarcza HttpClient lub MessageHandler, skonfiguruj serwer proxy tego transportu, zamiast oczekiwać, że osobna właściwość Proxy go nadpisze.

Dla konta proxy ustaw poświadczenia w WebProxy przed utworzeniem. Uwierzytelniają się one wobec pośrednika, a nie wobec Notification Hub.

Starsze przykłady podają NotificationHubClientSettings. Dopasuj typ ustawień i konstruktor udostępniane przez zainstalowany pakiet, zamiast mieszać tę nazwę z interfejsem API oczekującym NotificationHubSettings.

Powiązane artykuły