Обратный прокси-сервер 404
У нас есть API, сделанное из ядра .net, развернутое на сервере с обратным прокси, настроенным в iis.
Когда мы тестируем апи из чванства или напрямую по айпи адресу, скажем 10.18.0.1/api/Call, работает нормально. Однако, как только мы использовали обратный прокси, например https://mywebsite.com/api/Call, он возвращает ошибку 404 Not Found.
Для конечной точки реализована базовая аутентификация с использованием методов GET, POST и PUT. Если я попытаюсь вызвать тот же URL-адрес с помощью метода DELETE, он вернет 401.
Я действительно не DevOps и не разбираюсь в этом, поэтому небольшая помощь будет очень признательна.
================================================== ========================== ОБНОВЛЯТЬ: Проблема была обнаружена во входящем правиле. Код выглядит примерно так.
<rule name = "InBound001" stopProcessing = "true">
<match url = "^api/User/Profile(.*)" />
<action type = "Rewrite" url = "http://10.18.1.1/api/User/Profile/{R:1}" />
</rule>
Это давнее правило, которое раньше работало должным образом, однако, когда новое правило было добавлено в web.config, возникла ошибка. Обратите внимание, что новые правила уже были добавлены ранее, но ошибки не возникло, это произошло совсем недавно.
Проблема была исправлена, когда был удален последний «/» после /Profile в URL-адресе действия. URL-адрес назывался следующим образом: «http://myapp.com/api/User/Profile/Addess/1», «http://myapp.com/api/User/Profile/123» и т. д.
Я хотел бы подчеркнуть, что он работал нормально без проблем до сообщения о проблеме. Я просто хотел бы понять, почему он вдруг не работает и был исправлен, когда этот «/» был удален. Моя догадка является причиной совпадения URL-адреса, потому что в нем нет «/», но я не уверен. И разве он не должен по-прежнему совпадать, учитывая, что (.*) означает соответствие тому, что идет после?
Как настроить обратный прокси в конфигурационном файле? Я думаю, что это может быть проблема с конфигурацией.
@DingPeng Не совсем уверен в том, как, но DevOps использует переписывание URL-адресов и отображает правила входящей/исходящей связи в файле web.config.
Каковы ваши правила перезаписи URL? Основываясь на предоставленной вами информации, мы не знаем, что пошло не так.
Вы также можете использовать Failed Request Tracing для просмотра журнала ошибок.
@DingPeng Спасибо, я отредактировал свой вопрос, чтобы включить это.
Ответы 1
Это связано с тем, что если вы выполните переопределение URL-адреса, {R:1} будет /Address/1:
И URL, который вы переписываете:
http://10.18.1.1/api/User/Profile/{R:1}
Таким образом, окончательный переписанный URL будет выглядеть так:
http://10.18.1.1/api/Пользователь/Профиль//Адрес/1
Это приведет к появлению дополнительного «/» в URL-адресе.
решение:
решение 1. Изменить URL соответствия:
<rule name = "InBound001" stopProcessing = "true">
<match url = "^api/User/Profile/(.*)" />
<action type = "Rewrite" url = "http://10.18.1.1/api/User/Profile/{R:1}" />
</rule>
решение 2. Изменить URL-адрес действия:
<rule name = "InBound001" stopProcessing = "true">
<match url = "^api/User/Profile(.*)" />
<action type = "Rewrite" url = "http://10.18.1.1/api/User/Profile{R:1}" />
</rule>
Оба вышеуказанных решения могут решить эту проблему.
Спасибо за этот ответ. Это будет очень полезно для меня. Что меня все еще беспокоит, так это то, почему это работает так долгое время.
learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/… Узнайте, как отлаживать свои правила с помощью FRT.