У меня есть веб-API .NET Core 2.1 (с использованием 2.1.0-preview1-final), который отлично работает локально с помощью SignalR 1.0.0-preview1-final. Я использую для внешнего интерфейса приложение Angular с пакетом "@aspnet/signalr": "1.0.0-preview1-final", поэтому все соответствует, и у меня есть как конечные точки HTTP, так и концентраторы, работающие должным образом, когда я запускаю программы локально.
Когда я развертываю свой виртуальный сервер, у меня есть обратный прокси-сервер Nginx, который отправляет запросы всем приложениям, стоящим за ним. Я использую Docker, и у меня не было проблем с ним в других проектах, когда мы развертываем v1.0 всей экосистемы.
В этом конкретном сценарии у меня есть два отличия:
- У меня есть IdentityServer4, использующий AspNetIdentity, и мне пришлось удалить параметр
proxy_buffering offиз конфигурации Nginx, чтобы заставить его работать (после https://andrewlock.net/fixing-nginx-upstream-sent-too-big-header-error-when-running-an-ingress-controller-in-kubernetes/) - Я читал, что вам не следует делать 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 нет транспорта
------ КОНЕЦ ОБНОВЛЕНИЯ --------
Итак, мои вопросы:
Я нарушил подключение к 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, но и фактическое изображение докера.
