Archivos de registro IIS7, RewritePath e IIS

votos
10

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 controlador está demasiado adelantado en la tubería, pero si muevo la lógica a un evento posterior, que todo el proceso de 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.

Publicado el 09/12/2008 a las 18:15
fuente por usuario
En otros idiomas...                            


4 respuestas

votos
6

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.

Respondida el 23/02/2009 a las 21:15
fuente por usuario

votos
4

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 BeginRequesty luego la restablece al valor original 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()
    {

    }
}
Respondida el 17/02/2009 a las 19:14
fuente por usuario

votos
2

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.

Respondida el 17/02/2009 a las 19:34
fuente por usuario

votos
0

pregunta de siempre, pero he encontrado no me encontré con el problema cuando lo 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) Llamado RewritePath en el Page_PreInitcaso de default.aspx, para volver a escribir la URL y cadena de consulta como lo fue aprobada en la solicitud (es decir. la ubicación que no existe).

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

a) Regla Web.config asigna a /Default.aspx

b) Page_PreInit reescribe de nuevo a "/ CiertaPágina /? x = y".

El resultado de esto, en IIS 7 (Express y producción) es que el registro del servidor refleja "/ CiertaPágina" para el talón y "x = y" para la consulta, y todas las propiedades de petición de objetos reflejan la URL solicitada (inexistente) ( que es lo que quería).

El único efecto es raro, en IIS Express, el elemento de registro se escribe dos veces. Sin embargo, esto no sucede en la producción (Windows Server 2008 R2).

Respondida el 06/01/2013 a las 10:54
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more