SignalR .NET Core 2.1 не работает на прокси-контейнере с прокси

Question

У меня есть.NET Core 2.1 Web API (используя 2.1.0-preview1-final) нормально работает локально с помощью SignalR 1.0.0-preview1-final, Я использую для внешнего интерфейса приложение Angular, которое имеет пакет "@aspnet/signalr": "1.0.0-preview1-final" так что все совпадает, и у меня и конечные точки HTTP и концентраторы работают как положено, когда я запускаю программы локально.

При развертывании на моем виртуальном сервере у меня есть обратный прокси-сервер Nginx, который отправляет запрос всем приложениям за ним. Я использую Docker, и у меня не было проблем с ним в других проектах, когда мы развернули v1.0 всей экосистемы.

Различия у меня в этом конкретном сценарии две:

1. У меня есть IdentityServer4, использующий AspNetIdentity, и мне пришлось удалить proxy_buffering off вариант из конфигурации Nginx, чтобы заставить его работать (следуя https://andrewlock.net/fixing-nginx-upstream-sent-too-big-header-error-when-running-an-ingress-controller-in-kubernetes/)
2. Я читал, что вы не должны делать 1) при использовании SignalR, потому что у вас могут быть проблемы с ним - не уверен, так ли это сейчас.

Я фиксирую логи API и вижу, что когда я пытаюсь подключиться к концентратору, я возвращаюсь:

info: Microsoft.AspNetCore.Cors.Infrastructure.CorsService[4]
      Policy execution successful.
info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[2]
      Successfully validated the token.
info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[1]
      Authorization was successful.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 7.4652ms 200 application/json

Так что я предполагаю, что это правильно. Теперь на стороне клиента (приложение Angular): я вижу это:

Ошибка: не удалось установить соединение. Ошибка: доступных транспортов не найдено.

но если я проверяю ответ:

{"connectionId":"nHzKKYtp0ITwlEntjqLprA","availableTransports":[{"transport":"WebSockets","transferFormats":["Text","Binary"]},{"transport":"ServerSentEvents","transferFormats":["Text"]},{"transport":"LongPolling","transferFormats":["Text","Binary"]}]}

ОБНОВИТЬ

По сравнению с ответом при локальном запуске я получил:

{"connectionId":"4ea7b1ea-8754-472b-baef-527073872d2a","availableTransports":["WebSockets","ServerSentEvents","LongPolling"]}

Это означает, что нет никаких ограничений в отношении форматов передачи? Не уверен, что это тоже актуально... Это очень странно, здесь происходит то же самое: SignalR no transport

------ ОБНОВЛЕНИЕ КОНЕЦ --------

Итак, мои вопросы:

Не нарушил ли я связь с SignalR, потому что установил proxy_buffer? Если да, есть ли способ заставить и IS4, и SignalR работать за одним и тем же экземпляром Nginx? - Чтобы сделать вещи более сложными, я использую шаблон Nginx, который генерируется автоматически с помощью docker-gen.

Если мои изменения в Nginx не должны нарушать SignalR, почему не устанавливается соединение?

Спасибо!

ОБНОВИТЬ! НАЙТИ НОМЕР!!!

Я пишу это, потому что я думаю, что это может быть полезно для кого-то еще.

Проблема, с которой я столкнулся, заключалась в том, что я использовал preview1 как на клиенте, так и на API, но в тот день, когда я создал Dockerfile Я не мог получить FROM microsoft/dotnet:2.1.0-preview1-aspnetcore-runtime работать, поэтому я решил использовать preview2: FROM microsoft/dotnet:2.1.0-preview2-aspnetcore-runtime и это была проблема. Теперь я быстро изменил клиент и API, чтобы использовать предварительный просмотр SignalR, и я смог заставить соединение работать. Счастливые дни! Надеюсь, это будет полезно:) Так что не только клиент и API нуждаются в сопоставлении, но и фактическое изображение докера также должно быть выровнено.

Answer 1

Проблема, с которой я столкнулся, заключалась в том, что я использовал preview1 как на клиенте, так и на API, но в тот день, когда я создал Dockerfile, я не мог использовать FROM microsoft/dotnet:2.1.0-preview1-aspnetcore-runtime потому что у меня были проблемы с метаданными (взятые из ошибки), поэтому я решил использовать preview2: FROM microsoft/dotnet:2.1.0-preview2-aspnetcore-runtime и это была проблема. Теперь я быстро изменил клиент и API, чтобы использовать предварительный просмотр SignalR и я мог бы подключиться к работе. Счастливые дни! Надеюсь, что это полезно:) Так что не только клиент и API нуждаются в сопоставлении, но и фактическое изображение докера также должно быть выровнено.

Поэтому убедитесь, что у вас синхронизирована версия клиента, версия net Core сигнализатора и версия вашего рабочего времени. Dockerfile при создании изображения