Отслеживание неудачных запросов отлично работает для регистрации неудачных перезаписей. Я могу просмотреть файлы журнала и, по крайней мере, понять, почему перезапись не работает.
Шаблон регулярного выражения прошел проверку на соответствие ОК, но входные URL-адреса, которые я ввожу в браузере, даже не захватываются. Все URL-адреса, сопоставленные с действиями контроллера, фиксируются (мой веб-сайт - это приложение ASP. NET MVC), однако URL-адрес, который мне нужно переписать, не сопоставлен ни с каким, на странице отображается 404. Но я ожидаю, что это будет быть переписанным на какой-то рабочий URL-адрес (чтобы проверить его, чтобы вместо отображения 404 он был переписан на целевой URL-адрес и отображал возвращенный контент оттуда).
В моем правиле перезаписи URL используется Reverse Proxy
шаблон.
Надеюсь, то, что я понимаю, правильно. Как я могу это диагностировать? Моя цель - просто сделать что-то вроде превращения IIS в обратный прокси-сервер, перехватив все запросы через мой веб-сайт, проверить, соответствуют ли какие-либо из них определенному шаблону регулярного выражения, прежде чем запрашивать перезаписанный URL-адрес и возвращать содержимое исходному клиенту. 1009 * Обновление
Для тех, кто не знает о ASP. NET MVC:
Предположим, на моем веб-сайте есть контроллер с именем HomeController
с действием Index
и Сопоставленный с ним URL-адрес: /Home/Index
.
URL-адрес, который я имею в виду , не сопоставлен ни с каким действием здесь может быть /Home/TestProxy
Здесь HomeController
не предоставляет никаких действий TestProxy
и также нет никаких правил маршрутизации, отображающих /Home/TestProxy
на какое-либо действие. Таким образом, в этом случае приложение ASP. NET MVC покажет страницу 404
.
Как я сказал выше, для URL-адресов, сопоставленных с действительным действием контроллера, они кажутся захваченными и считается входными URL (перед проверкой на соответствие правилу перезаписи). Но для URL-адресов, не сопоставленных какому-либо действию контроллера (показано 404), я не вижу никаких записанных в журнал как входных URL-адресов (поэтому, конечно, они не будут проверяться на соответствие правилу перезаписи, и это не сработает).
Обновление 2
На самом деле мой протестированный URL-адрес даже не сопоставлен с контроллером, поэтому похоже, что он не регистрируется правилом Отслеживание неудачных запросов , которое я установил. Теперь я попытался использовать URL-адрес, сопоставленный с контроллером, но не с каким-либо действием (он все еще показывает 404), но успешно зарегистрирован правилом отслеживания неудачных запросов. Я вижу это в файле журнала:
<EventData>
<Data Name="ContextId">{80000034-0000-F000-B63F-84710C7967BB}</Data>
<Data Name="Pattern">testproxy/(.*)</Data>
<Data Name="Input">home/testproxy/index</Data>
<Data Name="Negate">false</Data>
<Data Name="Matched">true</Data>
</EventData>
Итак, он сообщил о шаблоне matched
, но все же на странице отображается 404, тогда как я ожидал, что он вернет содержимое из перезаписанного URL-адреса (который должен быть http://10.0.0.5/index
- Я подтверждаю, что этот URL работает, если запрашивается напрямую, это просто еще один простой опубликованный веб-сайт в локальной сети). Я даже не знаю, возможно ли это сейчас или я здесь что-то не так сделал.