У меня есть .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 всей экосистемы.
Различия, которые я имею в этом конкретном сценарии, две:
- У меня есть 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"]}]}
UPDATE
По сравнению с ответом при локальном запуске я получил:
{"connectionId":"4ea7b1ea-8754-472b-baef-527073872d2a","availableTransports":["WebSockets","ServerSentEvents","LongPolling"]}
Это означает, что нет никаких ограничений в отношении форматов передачи? Не уверен, что это тоже актуально ... Это очень странно, здесь происходит то же самое: SignalR без транспорта
------ ОБНОВЛЕНИЕ КОНЦА --------
Итак, мои вопросы:
Не нарушил ли я связь с SignalR, потому что установил proxy_buffer? Если так, есть ли способ заставить и IS4, и SignalR работать за одним и тем же экземпляром Nginx? - Для усложнения я использую шаблон Nginx, который генерируется автоматически с помощью docker-gen.
Если мои изменения в Nginx не должны нарушать SignalR, почему не устанавливается соединение?
Спасибо!
UPDATE! НАЙТИ НОМЕР !!!
Я пишу это, потому что думаю, что это может быть полезно для кого-то еще.
Проблема, с которой я столкнулся, заключалась в том, что я использовал 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 должны соответствовать, но и фактическое изображение докера также должно быть выровнено.