Опубликованный на веб-сервере API core8 работает из POSTMAN и из опубликованного интерфейса weserver, но ERR_CONNECTION_RESET из клиентского браузера

Я пытался объяснить все по этой теме, но вот моя проблема: У меня есть webApi, разработанный с помощью netcore 8, опубликованный на сервере Windows 2012 с IIS 8, и интерфейс Angular 15, размещенный на том же веб-сервере. Если я попытаюсь получить доступ к webapi с помощью PostMan, все будет работать правильно, и ответ будет отправлен обратно со всем, что мне нужно. Если я попытаюсь получить доступ к webapi с помощью клиента Angular напрямую через браузер на веб-сервере, он будет работать правильно (запрос поступает из формы входа). Если я попытаюсь получить доступ к webapi с помощью клиента Angular из клиентского браузера, у меня возникнет ошибка в консоли «ERR_CONNECTION_RESET». Пробовал с разных браузеров от разных клиентов: та же ошибка.

Исходный файл web.config API выглядит следующим образом:

<?xml version = "1.0" encoding = "utf-8"?>
<configuration>
    <location path = "." inheritInChildApplications = "false">
        <system.webServer>
            <handlers>
                <add name = "aspNetCore" path = "*" verb = "*" modules = "AspNetCoreModuleV2" resourceType = "Unspecified" />
            </handlers>
            <aspNetCore processPath = ".\WebApi.exe" stdoutLogEnabled = "true" stdoutLogFile = ".\logs\stdout" hostingModel = "inprocess" />
        </system.webServer>
    
    </location>
</configuration>

Есть предположения?

P.S.: WebApi изначально был написан для netcore7 и без проблем работал в той же среде.

Я попробовал более сложную версию web.config следующим образом:

<?xml version = "1.0" encoding = "utf-8"?>
<configuration>
    <location path = "." inheritInChildApplications = "false">
        <system.webServer>
            <handlers>
                <remove name = "WebDAV" />
                <remove name = "ExtensionlessUrlHandler-Integrated-4.0" />
                <remove name = "OPTIONSVerbHandler" />
                <remove name = "TRACEVerbHandler" />
                <add name = "ExtensionlessUrlHandler-Integrated-4.0" path = "*." verb = "*" type = "System.Web.Handlers.TransferRequestHandler" preCondition = "integratedMode,runtimeVersionv4.0" />
                <add name = "aspNetCore" path = "*" verb = "*" modules = "AspNetCoreModuleV2" resourceType = "Unspecified" />
            </handlers>
            <modules runAllManagedModulesForAllRequests = "true">
                <remove name = "WebDAVModule" />
                <remove name = "ApplicationInsightsWebTracking" />
                <add name = "ApplicationInsightsWebTracking" type = "Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition = "managedHandler" />
            </modules>
            <aspNetCore processPath = ".\WebApi.exe" stdoutLogEnabled = "true" stdoutLogFile = ".\logs\stdout" hostingModel = "inprocess" />
            <httpProtocol>
                <customHeaders>
                    <add name = "Access-Control-Allow-Headers" value = "Content-Type,Authorization"/>
                    <add name = "Access-Control-Allow-Methods" value = "GET, POST, PUT, DELETE, OPTIONS"/>
                </customHeaders>
            </httpProtocol>
        </system.webServer>
    
    </location>
</configuration>

Но все равно не работает.

Больше информации: в запуске webapi я добавил UseUrls("https://*:4000") в настройках приложения webapi я указал «AppURL»: «https://webserverName/:4000», который используется в app.config клиента angular: «apiEndpoint»: «https://webserverName:4000/».

Клиент Angular работает по http, а webApi — по https (с самозаверяющим сертификатом SSL).

Я бы сказал, что это проблема CORS

Andrei 17.06.2024 16:30

убедитесь, что как интерфейс, так и серверная часть используют один и тот же протокол: оба должны быть https. Конечные точки вашего API не могут иметь один и тот же URL-адрес... обычно это будет один и тот же домен, но с разными маршрутами/путями в конце. Пример: angular обслуживается из webservername.com (index.html, это angular обслуживается из специального каталога wwwroot), а конечные точки настроены в webservername.com/api (контроллеры .NET). Не знаю, почему вы указываете там порт. «ERR_CONNECTION_RESET» звучит как отказ в соединении, но вам нужно будет продолжить отладку на серверной части, чтобы получить более подробную информацию... может быть, на уровне IIS.

browsermator 17.06.2024 21:04

Если вы получаете сообщение об ошибке ERR_CONNECTION_RESET, это означает, что ваш интернет-браузер не может подключиться к серверу целевого веб-сайта. Вам необходимо убедиться, что необходимые порты (443 для HTTPS) открыты в брандмауэре Windows или любом другом установленном вами брандмауэре. Если брандмауэр блокирует входящий HTTPS-трафик, это может вызвать ошибку сброса соединения.

samwu 18.06.2024 05:30

@samwu Я вряд ли думаю, что это может быть проблема с брандмауэром, адрес, используемый клиентом Angular, тот же, что и в POSTMAN, где вызов работает правильно.

Jeze 18.06.2024 10:36

@browsermator, если возникла проблема с протоколом, он не должен работать и с самого веб-сервера, вместо этого все работает правильно.

Jeze 18.06.2024 10:40

@Андрей, что касается CORS, у моего сервиса в конфигурации есть useUrl с *, разве это не должно означать, что он принимает соединение, исходящее с каждого адреса? Разве это не должно в конечном итоге помешать даже соединению с POSTMAN?

Jeze 18.06.2024 10:40

У Postman нет правил CORS. Это делают только браузеры. Вы должны знать, что подстановочные знаки не допускаются для запросов с учетными данными и/или безопасности. Тем не менее, вы получите ошибку CORS, поэтому вам необходимо проверить всю серверную часть исключений на предмет этого ERR_CONNECTION_RESET.

browsermator 18.06.2024 19:06

Вы можете попытаться найти информацию об ошибках сервера, просмотрев файлы журналов или Event Vierer. Сообщение об ошибке может помочь вам определить проблему.

samwu 19.06.2024 11:56

В файлах журналов ISS есть только успешный вызов от клиента при использовании их в браузере с самого веб-сервера, но в них нет ошибок для клиента из удаленного браузера. Я также сделал несколько тестовых добавлений в «withOrigin»: localhost, имя веб-сервера и IP-адрес веб-сервера: не повезло.

Jeze 19.06.2024 12:23

Воспроизвести вашу проблему по вашему описанию сложно, предлагаю вам открыть дело через: support.microsoft.com.

samwu 24.06.2024 12:58
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Angular и React для вашего проекта веб-разработки?
Angular и React для вашего проекта веб-разработки?
Когда дело доходит до веб-разработки, выбор правильного front-end фреймворка имеет решающее значение. Angular и React - два самых популярных...
Эпизод 23/17: Twitter Space о будущем Angular, Tiny Conf
Эпизод 23/17: Twitter Space о будущем Angular, Tiny Conf
Мы провели Twitter Space, обсудив несколько проблем, связанных с последними дополнениями в Angular. Также прошла Angular Tiny Conf с 25 докладами.
Угловой продивер
Угловой продивер
Оригинал этой статьи на турецком языке. ChatGPT используется только для перевода на английский язык.
Мое недавнее углубление в Angular
Мое недавнее углубление в Angular
Недавно я провел некоторое время, изучая фреймворк Angular, и я хотел поделиться своим опытом со всеми вами. Как человек, который любит глубоко...
Освоение Observables и Subjects в Rxjs:
Освоение Observables и Subjects в Rxjs:
Давайте начнем с основ и постепенно перейдем к более продвинутым концепциям в RxJS в Angular
0
10
78
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

В конце концов я решил свою собственную проблему, которая действительно была проблемой CORS.

Мой интерфейс работал по http, а моя служба работала по https. Переключение моего сервиса на http (не желая иметь дело с сертификатами) помогло.

Думаю, мне нужно углубиться в CORS.

Другие вопросы по теме