Невозможно изменить код ответа IIS с исходящим правилом URL Rewrite

Я пытаюсь настроить правило перезаписи URL-адреса IIS для соответствия 403 ответам в результате того, что кто-то пытается перейти к каталогу, когда просмотр каталогов отключен. Я хочу, чтобы затем перенаправить их на обычные страницы пользовательских ошибок ASP.NET, которые я определил для 404.

Вот что я имею в настоящее время:

<outboundRules>
  <!-- By default, browsing a directory with no default resource will return 403 -->
  <rule name="Directory browsing location">
    <match serverVariable="RESPONSE_LOCATION" pattern="(.*)" />
    <conditions>
      <add input="{RESPONSE_STATUS}" pattern="^403" />
    </conditions>
    <action type="Rewrite" value="/Error/PageNotFound?aspxerrorpath={PATH_INFO}"/>
  </rule>
  <rule name="Directory browsing status code" patternSyntax="ExactMatch">
    <match serverVariable="RESPONSE_STATUS" pattern="403" />
    <action type="Rewrite" value="302" />
  </rule>
</outboundRules>

Мое предположение заключается в том, что оно должно быть исходящим правилом и что мне нужно переписать как код состояния, так и добавить заголовок ответа на местоположение, хотя последний не существовал бы в любом случае с исходным ответом 403.

Поведение на данный момент - это... ничего. Я все еще вижу 403s независимо от того, сколько настроек я делаю. Какие-нибудь идеи там?

Кстати, нет, на сайте нет никаких законных 403s, которые будут проглочены в результате этого. Я мог бы также создавать входящие правила для каждого пути, которые могут привести к выполнению условия, но это не очень масштабируемое.

Ответы

Ответ 1

URL Rewrite имеет дескриптор почти всего, но не код состояния HTTP, поскольку он находится за пределами заголовка ответа. Поэтому, к сожалению, URL Rewrite не может с этим поделать, или, по крайней мере, не тот, который я когда-либо мог найти. Я хотел делать подобные вещи много раз. Обратите внимание: вы можете проверить статус с условием, используя {RESPONSE_STATUS}, но вы не можете его обновить.

Ответ от @RyanCEI - это то, что я бы рекомендовал. Чтобы добавить к этому, вы можете использовать subStatusCode для охвата ошибки до всего лишь 403.14, и только для тестирования убедитесь, что вы либо проверяете off-box, либо установите для параметра errorMode значение Custom, поскольку по умолчанию IIS не будет отображать пользовательскую ошибку страниц при тестировании в локальном поле.

Вот пример config, который делает оба из них.

    <httpErrors errorMode="Custom">
        <error statusCode="403" subStatusCode="14" path="/errorpage.htm" responseMode="ExecuteURL" />
    </httpErrors>

После тестирования вы можете отключить errorMode = "Custom".

Ответ 2

Не уверен, что это помогает, так как это не правило перезаписи, но это заставит 403 перейти на страницу с ошибкой, используя раздел httpErrors в файле web.config:

<configuration>
    <system.web>
      <compilation debug="false" targetFramework="4.5" />
      <httpRuntime targetFramework="4.5" />
      <customErrors defaultRedirect="~/errorpage.html" mode="On">
      </customErrors>
    </system.web>
  <system.webServer>
    <httpErrors>
      <remove statusCode="404" subStatusCode="-1" />
      <error statusCode="404" prefixLanguageFilePath="" path="/errorpage.html" responseMode="ExecuteURL" />
      <remove statusCode="403" subStatusCode="-1" />
      <error statusCode="403" prefixLanguageFilePath="" path="/errorpage.html" responseMode="ExecuteURL" />
    </httpErrors>
    <defaultDocument>
      <files>
        <remove value="default.aspx" />
        <remove value="iisstart.htm" />
        <remove value="index.htm" />
        <remove value="Default.asp" />
        <remove value="Default.htm" />
      </files>
    </defaultDocument>
  </system.webServer>
</configuration>

Ответ 3

Я помню с SharePoint, когда у нас была эта проблема, мы вошли в регистратор доменов для наших доменных имен и поместили записи DNS для пересылки вещей (я думаю, что это записи CNAME). Это был беспорядок, который все это синхронизировал, но это был единственный способ заставить его работать. HTTP и URL Rewrites в IIS не работали в некоторых случаях с SharePoint по крайней мере.

Ответ 4

Мне тоже не повезло - но я подозреваю, что в этом ответе может быть намек

http://forums.iis.net/t/1200342.aspx?URL+rewrite+rule+to+capture+response+status+503+and+redirect

Процитировать из своего ответа: "Однако в 503 случаях запросы никогда не приходят к рабочему процессу, а ответы 503 поступают напрямую из http.sys".

Я подозреваю, что 403s никогда не могут перейти в процесс IIS и не могут быть перезаписаны.