84 votes

Comment faire pour forcer l'ensemble d'IE Mode de Compatibilité de partir du côté serveur?

Dans un domaine d'un environnement contrôlé, je suis la recherche que le mode de compatibilité est déclenchée sur certains clients (windows xp/Win7, IE8/IE9), même lorsque nous sommes en fournissant un X-UA balises !DOCTYPE définition et la "IE=Edge" en-têtes de réponse. Ces clients ont l' "afficher les sites intranet dans affichage de compatibilité" dans la case cochée. Ce qui est précisément ce que j'essaie de remplacer.

Ce qui suit est la documentation que j'ai utilisé pour essayer de comprendre comment IE décide de déclencher le mode de compatibilité.

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

Les propriétaires de sites sont toujours en contrôle de leur contenu. Les propriétaires de Site peuvent choisir d'utiliser le X-UA-Compatible tag pour être absolument déclarative sur la façon dont ils aimeraient leur site à afficher et de définir des Normes de pages en mode IE7 Normes. L'utilisation de la X-UA-Compatible tag remplace l'Affichage de Compatibilité sur le client.

Google pour "la Définition de la Compatibilité des documents", malheureusement, le moteur de SPAM ne me permet pas de poster plus de 2 url.

C'est un ASP .NET web app et comprend les définitions suivantes sur la page principale:

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

et web.config

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

J'ai utilisé un violon pour vérifier que la tête est en effet injecté correctement.

Ma compréhension est que, avec ces paramètres, je devrais être capable de remplacer le "Afficher les sites intranet dans Affichage de Compatibilité" paramètres de votre navigateur. Mais selon le client, j'ai trouvé que certains d'entre eux seront encore déclencher le mode de compatibilité. Il semble également être en baisse à niveau de la machine plutôt une politique de groupe, puisque je obtenir des résultats différents, même quand je l'utilise avec le même ensemble d'informations sur les différents clients.

Désactiver les Paramètres d'Affichage de Compatibilité case fait le tour. Mais le véritable but est de s'assurer que l'application est rendue exactement de la même façon, indépendamment des paramètres du client.

Toutes les pensées et ce que je pourrais être éventuellement manquantes? Est-il possible de forcer, c'est à dire toujours de rendre les pages, sans déclencher Compat mode?

un million de mercis,

Jaume

PS: le site est actuellement en développement et est bien sûr pas dans la liste de compatibilité de Microsoft, mais j'ai aussi vérifié juste au cas où.

Google pour "la Compréhension de la Liste d'Affichage de Compatibilité", malheureusement, le moteur de SPAM ne me permet pas de poster plus de 2 url.

45voto

Sam Points 3542

J'ai trouvé des problèmes avec les deux façons de le faire:

  1. De le faire avec des en-têtes personnalisés (<customHeaders>) dans le web.config permet différents déploiements de même pour l'application de cet ensemble différemment. Je vois cela comme une chose de plus qui peut aller mal, donc je pense que c'est mieux si l'application spécifie dans le code. Aussi, IIS6 ne prend pas en charge cette.

  2. Y compris HTML, <meta> balise dans un site Web Formulaires Page Maître ou MVC Mise en Page semble mieux que le précédent. Toutefois, si certaines pages ne sont pas hériter de ces le tag doit être dupliqué, donc il y a un potentiel de maintenabilité et la fiabilité problème.

  3. Le trafic réseau peut être réduit que de l'envoi de l' X-UA-Compatible - tête pour les clients Internet Explorer.

Bien Structuré Applications

Si votre application est structurée d'une manière qui provoque toutes les pages pour finalement hériter d'une racine unique page, inclure l' <meta> balise comme indiqué dans les autres réponses.

Applications Héritées

Sinon, Je pense que la meilleure façon de le faire est d'ajouter automatiquement l'en-tête HTTP à tous HTML réponses. Une façon de faire cela est d'utiliser 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 indique que IE doit toujours utiliser son dernier moteur de rendu pour le rendu de la page. Ce devrait veiller à ce que la page est affichée de manière cohérente avec les autres navigateurs et conforme aux normes.

Il semble que les modules HTTP sont souvent inscrites dans le web.fichier de config, mais cela nous ramène à la première difficulté. Cependant, vous pouvez vous inscrire par programme Mondial.asax comme ceci:

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

Notez qu'il est important que le module est - static , et non instancié en Init , de sorte qu'il n'est qu'une instance par l'application. Bien sûr, dans une application réelle d'un conteneur IoC devrait probablement être la gestion de cette.

Avantages

  • Permet de surmonter les problèmes décrits au début de cette réponse.

Inconvénients

  • Site admins n'ont pas de contrôle sur la valeur d'en-tête. Cela pourrait être un problème si une nouvelle version d'Internet Explorer vient de l'extérieur et affecte négativement le rendu du site. Toutefois, ce problème pourrait être surmonté par le module de lire la valeur d'en-tête de l'application, le fichier de configuration au lieu d'utiliser une valeur codée en dur.
  • Cela peut nécessiter la modification de travailler avec ASP.NET MVC.
  • Cela ne fonctionne pas pour les pages HTML statiques.
  • L' PreSendRequestHeaders événement dans le code ci-dessus ne semble pas le feu dans IIS6. Je n'ai pas trouvé comment résoudre ce bug encore.

39voto

Gideon Points 209

Mon changement d'en-tête à la suite de résoudre le problème:

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

17voto

Andrew Flierman Points 3516

Mise à jour: les informations les Plus utiles Quelle est la différence si "<meta http-equiv="X-UA-Compatible" content="IE=edge">" existe ou pas?

Peut-être cette url peut vous aider à: l'Activation des Modes Navigateur avec Doctype

Edit: aujourd'Hui, nous avons été en mesure de remplacer l'affichage de compatibilité avec: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X