c# - stopprocessing - Archivos de registro IIS7, RewritePath e IIS

web config stopprocessing true

Question

Estoy usando Context.RewritePath () en la aplicación ASP.NET 3.5 ejecutándose en IIS7.

Lo estoy haciendo en la aplicación BeginRequest y todo funciona en el archivo.

Las solicitudes de / sports se reescriben correctamente a default.aspx? Id = 1, y así sucesivamente.

El problema es que en mi registro IIS veo solicitudes GET para /Default.aspx?id=1 y no para / sports.

Este tipo de código funcionó perfectamente bajo IIS6.

El uso del módulo Microsoft Rewrite no es una opción, debido a alguna lógica comercial que debe implementarse.

Gracias.

EDITAR:

Parece que mi manejador está demasiado adelantado en la tubería, pero si muevo la lógica a un evento posterior, que todo lo de la reescritura no funciona (es demasiado tarde, StaticFileHandler recoge mi solicitud).

Busqué en Google y busqué en Google, pregunté por ahí, ¿no puedo creer que nadie tenga este problema?

EDITAR:

¡Ay! Esto es lo que encontré en el foro de IIS:

"Esto se debe a que en el modo integrado, IIS y asp.net comparten una interconexión común y ahora IIS ve RewritePath, mientras que en IIS6, ni siquiera lo veía IIS; puede solucionarlo utilizando el modo clásico, que se comportaría como IIS6 ".

Actualización final : Por favor, eche un vistazo a mi respuesta a continuación , la he actualizado con los resultados después de más de un año en el entorno de producción.

Answer 1

He tenido exactamente el mismo problema. Una forma de evitar esto es usar Server.Transfer en lugar de Context.RewritePath. Server.Transfer no reinicia todo el ciclo de vida de la página, por lo que la URL original aún se registrará. Asegúrese de pasar "verdadero" para el parámetro "preserveForm" para que las colecciones QueryString y Form estén disponibles para la segunda página.

Answer 2

Puede establecer la ruta de regreso al valor original después de que se haya procesado la solicitud, pero antes de que el módulo de registro de IIS escriba la entrada de registro.

Por ejemplo, este módulo reescribe la ruta en BeginRequest y luego vuelve a establecer el valor original en EndRequest . Cuando se utiliza este módulo, la ruta de acceso original aparece en el archivo de registro de IIS:

public class RewriteModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.BeginRequest += OnBeginRequest;
        context.EndRequest += OnEndRequest;
    }

    static void OnBeginRequest(object sender, EventArgs e)
    {
        var app = (HttpApplication)sender;
        app.Context.Items["OriginalPath"] = app.Context.Request.Path;
        app.Context.RewritePath("Default.aspx?id=1");
    }

    static void OnEndRequest(object sender, EventArgs e)
    {
        var app = (HttpApplication)sender;
        var originalPath = app.Context.Items["OriginalPath"] as string;
        if (originalPath != null)
        {
            app.Context.RewritePath(originalPath);
        }
    }

    public void Dispose()
    {

    }
}

Answer 3

Después de algunas investigaciones, finalmente encontré una solución al problema.

He reemplazado las llamadas al método Context.RewritePath () con el nuevo método (introducido en ASP.NET 3.5) Context.Server.TransferRequest () .

Parece obvio ahora, pero no el evento Senior Dev Engineer en el equipo de IIS Core pensó en eso.

Lo he probado para problemas de sesión, autenticación, devolución de datos, querystring, ... y no encontré ninguno.

Tommorow implementaré el cambio en un sitio de tráfico muy alto, y pronto sabremos cómo funciona realmente. :)

Volveré con la actualización.

La actualización: la solución aún no está completamente en mis servidores de producción, pero se ha probado y funciona, y hasta donde puedo decir hasta ahora, es una solución a mi problema. Si descubro algo más en producción, publicaré una actualización.

La actualización final: Tengo esta solución en producción durante más de un año y ha demostrado ser una solución buena y estable sin ningún problema.

Answer 4

Pregunta anterior, pero descubrí que no encontré su problema cuando hice lo siguiente:

a) Una regla de reescritura en web.config para dirigir todas las solicitudes a /default.aspx, por ejemplo:

    <rule name="all" patternSyntax="Wildcard" stopProcessing="true">
      <match url="*"/>
      <action type="Rewrite" url="/default.aspx"/>
    </rule>

b) Se llama RewritePath en el evento Page_PreInit de default.aspx, para volver a escribir el URL y la cadena de consulta como lo que se pasó en la solicitud (es decir, la ubicación que no existe).

Por ejemplo, solicito "/ somepage /? X = y" (que no existe).

a) La regla Web.config lo mapea en /default.aspx

b) Page_PreInit lo vuelve a escribir en "/ somepage /? x = y".

El resultado de esto, en IIS 7 (Express y producción) es que el registro del servidor refleja "/ somepage" para stub y "x = y" para la consulta, y todas las propiedades del objeto Request reflejan la URL solicitada (no existente) ( que es lo que yo quería).

El único efecto extraño es que, en IIS Express, el elemento de registro se escribe dos veces. Sin embargo, esto no ocurre en producción (Windows Server 2008 R2).