SignalR с IIS 10 и ARR 3.0

Question

Мы не можем заставить SignalR работать при использовании ARR 3.0 в качестве обратного прокси-сервера перед нашей машиной разработки Visual Studio. Соединение успешно установлено, но исходный кадр, который должен быть отправлен с сервера SignalR после установления соединения, никогда не отправляется, по сути, никакие кадры не могут быть отправлены, это заставляет клиента отказаться от соединения WebSocket. Подводя итог, «соединение через веб-соединение может устанавливать, но не может передавать кадры».

Приложение MVC работает без обратного прокси.

Мы попробовали все предложенные решения в следующих потоков:

• Websockets reverse proxy in IIS 8
• http://matthewmanela.com/blog/using-signalr-in-an-arr-cluster/

Скриншот "переговоры" -request.

Скриншот «connect» -request.

EDIT 1

Оказывается, что подключенный кадр посылается, но не по дороге. Это видно через Wireshark по шлейфу.

EDIT 2

Оказывается, что SignalR работает с ARR, когда я не добавляя суффикс к URL-адресу. Другими словами:

• http://websitea.local =>http://websiteb.local отлично работает
• http://websitea.local/portal =>http://websiteb.local не работает

Answer 1

Таким образом, нам удалось решить этот вопрос в вопросе, и мы докопались в основной чтобы иметь возможность четко воспроизвести проблему. Это связано с порядком, в котором выполняется переписывание, что мы сделали, так это то, что мы создали вспомогательный метод в нашем приложении ASP.NET MVC, который будет переписывать URL-адрес входного параметра, если заголовки HTTP из упорядоченного запроса содержат наш путь перезаписи суффикс.

public static class RouteHelper 
{ 
    public static string Url(string url) 
    { 
     string orginalUrl = HttpContext.Current?.Request.Headers["X-Original-URL"]; 
     if (!string.IsNullOrEmpty(orginalUrl)) 
     { 
      if (orginalUrl.StartsWith("/" + "portal", true, CultureInfo.InvariantCulture) 
       || orginalUrl.StartsWith("portal", true, CultureInfo.InvariantCulture)) 
      { 
       url = "/" + "portal" + url; 
      } 
     } 
     return url; 
    } 
} 

Мы использовали этот метод для заданного URL втулки/соединения SignalR следующим образом:

$.connection.hub.url = '@RouteHelper.Url("/signalr")' 

В результате будет $ .connection.hub.url = «@ RouteHelper.Url (»/portal/signalr ") '

Легко думать, что это даст тот же результат, что и создание правила исходящего переписывания, которое будет делать это, но это неверно.

Ответ, который возвращается клиенту из прокси-сервера, будет таким же, но связь между прокси-сервером и веб-сервером будет неисправна.

Вместо этого мы создали исходящее правило для этого, который выглядел так:

<rule name="SignalRReverseProxySignalRHubsUrl"> 
    <match filterByTags="None" pattern="connection.hub.url.*=.*['\&quot;](.*)['\&quot;]" /> 
    <action type="Rewrite" value="connection.hub.url = &quot;/portal{R:1}&quot;" /> 
</rule> 

Я не могу объяснить, что происходит внутренняя между обратными прокси и серверными веб-серверов, который вызывает SignalR кадры не для того чтобы приехать но я могу подтвердить, что все переписывание URL-адресов должно выполняться в прокси и логике приложения, которое имитирует одно и то же переписывание, не будет работать должным образом, по крайней мере, не так, как описано выше.