the page internet ie11 compatible change attached asp.net internet-explorer ie8-compatibility-mode x-ua-compatible

asp.net - page - ¿Cómo se puede desactivar forzosamente el modo de compatibilidad de IE desde el servidor?



the attached page targets document mode 7 (4)

En un entorno controlado por dominio, descubro 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 respuesta "IE = Edge" encabezados Estos clientes tienen marcada la casilla de verificación "Mostrar sitios de intranet en la vista de compatibilidad". Que es precisamente lo que intento anular.

La siguiente es la documentación que he usado para tratar de entender 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 del sitio pueden optar por usar la etiqueta X-UA-Compatible para declarar de manera absoluta cómo les gustaría que su sitio se muestre y para asignar 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 compatibilidad de documentos" , por desgracia, el motor de SPAM no me permite publicar más de 2 URL.

Esta es una aplicación web ASP .NET 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 comprobar que el encabezado se está inyectando correctamente.

Según tengo entendido, con esta configuración debería poder anular la configuración del navegador "Mostrar sitios de intranet en la Vista de compatibilidad". Pero dependiendo del cliente, he encontrado 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 clientes diferentes.

Desactivar la casilla de verificación Configuración de vista de compatibilidad hace el truco. Pero el objetivo real es asegurarse de que la aplicación se represente exactamente de la misma manera, independientemente de la configuración del cliente.

¿Alguna idea y lo que posiblemente podría perder? ¿Es posible obligar a IE a renderizar 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 vista de compatibilidad" , lamentablemente el motor de SPAM no me permite publicar más de 2 URL.

Cambiar mi encabezado a lo siguiente resuelve el problema:

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

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

  1. Hacer esto con encabezados personalizados ( <customHeaders> ) en web.config permite diferentes implementaciones de la misma aplicación para tener este conjunto 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 es compatible con esto .

  2. Incluir una etiqueta HTML <meta> en una página maestra de formularios web o en una página MVC Layout parece mejor que la anterior. Sin embargo, si algunas páginas no heredan de ellas, entonces la etiqueta debe duplicarse, por lo que existe un posible problema de mantenimiento y confiabilidad.

  3. El tráfico de red podría reducirse enviando únicamente el encabezado X-UA-Compatible a los clientes de Internet Explorer.

Aplicaciones bien estructuradas

Si su aplicación está estructurada de manera tal que todas las páginas finalmente hereden de una sola página raíz, incluya la etiqueta <meta> 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 hacerlo es usar 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 representación (en lugar del modo de compatibilidad) para representar 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 de esta manera:

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 sea static y no esté instanciado en Init por lo que solo hay una instancia por aplicación. Por supuesto, en una aplicación del mundo real, un contenedor IoC probablemente debería estar gestionando 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 sale una nueva versión de Internet Explorer y afecta negativamente a la prestación del sitio web. Sin embargo, esto podría superarse haciendo que el módulo lea el valor del encabezado desde el archivo de configuración de la aplicación en lugar de usar un valor codificado.
  • Esto puede requerir modificaciones para trabajar con ASP.NET MVC.
  • Esto no funciona para páginas HTML estáticas.
  • El evento PreSendRequestHeaders en el código anterior no parece activarse en IIS6. Todavía no he resuelto cómo resolver este error.

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(); });