Azure Notification Hubs .NET: кое поставување на прокси победува?

Конфигурирајте NotificationHubSettings.Proxy или доставен HTTP транспорт, имајќи го предвид приоритетот на HttpClient и MessageHandler во конструкторот.

Во Notification Hubs .NET API со 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.

Поврзани статии