¿Cómo desactivar forzosamente el modo de compatibilidad de IE desde el lado del servidor?

Question 1

En un entorno controlado por dominio, encuentro que el modo de compatibilidad se activa en ciertos clientes (winXP / Win7, IE8 / IE9) incluso cuando proporcionamos etiquetas X-UA, una definición! DOCTYPE y una respuesta "IE = Edge" encabezados. Estos clientes tienen marcada la casilla de verificación "mostrar sitios de intranet en vista de compatibilidad". Que es precisamente lo que intento anular.

La siguiente es la documentación que he usado para intentar comprender cómo IE decide activar realmente el modo de compatibilidad.

http://msdn.microsoft.com/en-us/library/ff406036%28v=VS.85%29.aspx

http://blogs.msdn.com/b/ie/archive/2009/02/16/just-the-facts-recap-of-compatibility-view.aspx

Los propietarios del sitio siempre tienen el control de su contenido. Los propietarios de sitios pueden optar por utilizar la etiqueta X-UA-Compatible para ser absolutamente declarativos sobre cómo les gustaría que se muestre su sitio y para asignar las páginas del modo Estándares a los Estándares IE7. El uso de la etiqueta X-UA-Compatible anula la Vista de compatibilidad en el cliente.

Google para "Definir la compatibilidad de documentos" , lamentablemente el motor de SPAM no me permite publicar más de 2 URL.

Esta es una ASP .NETaplicación web e incluye las siguientes definiciones en la página maestra:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<head>
   <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
</head>

y web.config

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <clear />
      <add name="X-UA-Compatible" value="IE=Edge" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

He usado Fiddler para verificar que el encabezado se esté inyectando correctamente.

Tengo entendido que con esta configuración debería poder anular la configuración del navegador "Mostrar sitios de intranet en Vista de compatibilidad". Pero, dependiendo del cliente, he descubierto que algunos de ellos todavía activarán el modo de compatibilidad. También parece estar en el nivel de la máquina en lugar de una configuración de grupo de políticas, ya que obtengo resultados diferentes incluso cuando uso con el mismo conjunto de credenciales en diferentes clientes.

Deshabilitar la casilla de verificación Configuración de vista de compatibilidad funciona. Pero el propósito real es asegurarse de que la aplicación se procese exactamente de la misma manera, independientemente de la configuración del cliente.

¿Alguna idea y lo que podría estar perdiendo? ¿Es posible obligar a IE a representar siempre las páginas sin activar el modo Compat?

un millón de gracias,

Jaume

PD: el sitio está actualmente en desarrollo y, por supuesto, no está en la lista de compatibilidad de Microsoft, pero también lo he comprobado por si acaso.

Google para "Comprender la lista de vistas de compatibilidad" , lamentablemente el motor de SPAM no me permite publicar más de 2 URL.

Question 2

Encontré problemas con las dos formas comunes de hacer esto:

Hacer esto con encabezados personalizados ( <customHeaders>) en web.config permite que diferentes implementaciones de la misma aplicación tengan esta configuración de manera diferente. Veo esto como una cosa más que puede salir mal, así que creo que es mejor si la aplicación especifica esto en el código. Además, IIS6 no admite esto .
Incluir una <meta>etiqueta HTML en una página maestra de formularios web o en una página de diseño MVC parece mejor que lo anterior. Sin embargo, si algunas páginas no heredan de estas, la etiqueta debe duplicarse, por lo que existe un problema potencial de mantenimiento y confiabilidad.
El tráfico de red se puede reducir enviando solo el X-UA-Compatibleencabezado a los clientes de Internet Explorer.

Aplicaciones bien estructuradas

Si su aplicación está estructurada de una manera que hace que todas las páginas hereden finalmente de una sola página raíz, incluya la <meta>etiqueta como se muestra en las otras respuestas .

Aplicaciones de legado

De lo contrario, creo que la mejor manera de hacerlo es agregar automáticamente el encabezado HTTP a todas las respuestas HTML. Una forma de hacer esto es usando un IHttpModule:

public class IeCompatibilityModeDisabler : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PreSendRequestHeaders += (sender, e) => DisableCompatibilityModeIfApplicable();
    }

    private void DisableCompatibilityModeIfApplicable()
    {
        if (IsIe && IsPage)
            DisableCompatibilityMode();
    }

    private void DisableCompatibilityMode()
    {
        var response = Context.Response;
        response.AddHeader("X-UA-Compatible", "IE=edge");
    }

    private bool IsIe { get { return Context.Request.Browser.IsBrowser("IE"); } }

    private bool IsPage { get { return Context.Handler is Page; } }

    private HttpContext Context { get { return HttpContext.Current; } }

    public void Dispose() { }
}

IE=edge indica que IE debería usar su último motor de renderizado (en lugar del modo de compatibilidad) para renderizar la página.

Parece que los módulos HTTP a menudo se registran en el archivo web.config, pero esto nos lleva de vuelta al primer problema. Sin embargo, puede registrarlos programáticamente en Global.asax así:

public class Global : HttpApplication
{
    private static IeCompatibilityModeDisabler module;

    void Application_Start(object sender, EventArgs e)
    {
        module = new IeCompatibilityModeDisabler();
    }

    public override void Init()
    {
        base.Init();
        module.Init(this);
    }
}

Tenga en cuenta que es importante que el módulo esté staticy no instanciado Initpara que solo haya una instancia por aplicación. Por supuesto, en una aplicación del mundo real, un contenedor de IoC probablemente debería gestionar esto.

Ventajas

Supera los problemas descritos al comienzo de esta respuesta.

Desventajas

Los administradores del sitio web no tienen control sobre el valor del encabezado. Esto podría ser un problema si aparece una nueva versión de Internet Explorer y afecta negativamente la representación del sitio web. Sin embargo, esto podría superarse haciendo que el módulo lea el valor del encabezado del archivo de configuración de la aplicación en lugar de usar un valor codificado.
Esto puede requerir modificaciones para funcionar con ASP.NET MVC.
Esto no funciona para páginas HTML estáticas.
El PreSendRequestHeadersevento en el código anterior no parece activarse en IIS6. Todavía no he descubierto cómo resolver este error.

Question 3

Cambiar mi encabezado a lo siguiente resuelve el problema:

<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

Question 4

Actualización: más información útil ¿Qué hace <meta http-equiv = "X-UA-Compatible" content = "IE = edge">?

Quizás esta URL pueda ayudarlo: Activar modos de navegador con Doctype

Editar: hoy pudimos anular la vista de compatibilidad con: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />

Question 5

Para los desarrolladores de Node / Express, puede usar middleware y configurarlo a través del servidor.

app.use(function(req, res, next) {
  res.setHeader('X-UA-Compatible', 'IE=edge');
  next();
});