asp.net - net - url rewrite forward

No se puede cambiar el código de respuesta de IIS con la regla de salida de reescritura de URL

Question

Estoy intentando configurar una regla de Reescritura de URL de IIS para que coincida con 403 respuestas como resultado de que alguien intente buscar un directorio cuando la búsqueda de directorios está deshabilitada. Luego quiero redirigirlos a la página de errores personalizados de ASP.NET habitual que he definido para 404s.

Esto es lo que tengo actualmente:

<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>

Supongo que debe ser una regla de salida y que debo volver a escribir tanto el código de estado como agregar el encabezado de respuesta de ubicación, aunque este último no existiría de todos modos con la respuesta 403 original.

El comportamiento en este momento es ... nada. Todavía estoy viendo 403s, no importa cuántos ajustes haga. ¿Alguna idea por ahí?

Incidentalmente, no, no hay ningún 403 legítimo en el sitio que pueda ser tragado como resultado de esto. También podría crear reglas de entrada para cada ruta que podrían dar como resultado el cumplimiento de la condición, pero eso no es muy escalable.

Answer 1

La reescritura de URL controla casi todo, pero no el código de estado HTTP, ya que está fuera del encabezado de respuesta. Desafortunadamente, URL Rewrite no puede hacer nada con esto, o al menos no que haya podido encontrar. He querido hacer cosas similares muchas veces. Tenga en cuenta que puede verificar el estado con una condición utilizando {RESPONSE_STATUS}, pero no puede actualizarlo.

La respuesta de @RyanCEI es lo que recomendaría. Para agregar a eso, puedes usar subStatusCode para extender el error a solo 403.14, y solo para pruebas, asegúrate de probar fuera de la casilla o de configurar el errorMode en Custom ya que, de manera predeterminada, IIS no mostrará el error personalizado páginas al probar en el cuadro local.

Aquí hay un ejemplo de configuración que hace ambos.

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

Después de la prueba, puede desactivar el errorMode = "Personalizado".

Answer 2

No estoy seguro de si esto ayuda, ya que no es una regla de reescritura, pero esto forzará a 403 a su página de error usando la sección httpErrors de 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>

Answer 3

Recuerdo que con SharePoint, cuando tuvimos este problema, ingresamos al registrador de dominios para nuestros nombres de dominio y pusimos registros DNS para reenviar cosas (creo que eran registros CNAME). Fue un desastre mantenerlo todo sincronizado, pero era la única forma en que podíamos hacerlo funcionar. Las reescrituras de HTTP y URL en IIS no funcionaron en algunos casos al menos con SharePoint.

Answer 4

Tampoco he tenido mucha suerte, pero sospecho que podría haber una pista en esta respuesta.

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

Para citar de su respuesta: "Sin embargo, en 503 casos, las solicitudes nunca llegan al proceso de trabajo, y las 503 respuestas provienen de http.sys directamente".

Sospecho que los 403 nunca pueden ir al proceso de IIS y no pueden reescribirse.