Wird die X-UA-Kompatiblen http-header tatsächlich für IE9?

Arbeite ich an einem web-Produkt, das möglicherweise gehostet werden, die sich als eine intranet-site. Ich bin auf der Suche nach einem programmatischen Weg, um IE9 vor dem Abrutschen in die IE9 Kompatibilitätsansicht-browser-Modus, obwohl 'Anzeigen Intranetsites in Kompatibilitätsansicht Anzeigen' kann sein auf.

Teste ich diese html-Seite:

<!DOCTYPE HTML>

<html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=9" />
        <title>Company</title>
    </head>
    <body>
    </body>
</html>

Ich habe diese in der IIS-config:

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

als hier empfohlen: https://stackoverflow.com/a/5887546, und überprüft den response-Header in IE9 und siehe:

X-UA-Compatible     IE=Edge

Aber die Seite noch setzt der browser in der Kompatibilitätsansicht im browser-mode.

Zeigt die Konsole:

HTML1202: http://intranet-site/test.html is running in Compatibility View because 'Display intranet sites in Compatibility View' is checked. 
test.html

Gibt es eine ähnliche Frage hier: https://stackoverflow.com/a/3726605/1279516, in denen ein Kommentar von Jacob auf die gewählte Antwort deutet darauf hin, dass im IE9, es gibt nichts, was Sie tun können, um das überschreiben der 'Display Intranetsites in Kompatibilitätsansicht Anzeigen" - Einstellung. Aber sein Kommentar ist der einzige Ort, den ich gefunden habe, die Erwähnung dieses. Kann das jemand bestätigen oder dementieren, dass die Aussage?

Gibt es etwas, das ich versuchen kann? Ich sollte nicht zu sagen alle Kunden, die Bereitstellung unseres Produkts zu deaktivieren Sie die "Display Intranetsites in Kompatibilitätsansicht Anzeigen' browser-Einstellung für alle Ihre Nutzer.

  • Die Dokument-Modus sehen Sie in den IE-Entwicklungs-tools für Ihre Website?
  • Der Dokument-Modus ist eigentlich IE9-standards. Sorgt dafür, dass das rendering erfolgt in den standards-Modus, aber nicht, dass alle javascript-Funktionen verfügbar sind, richtig?
  • Nein, eigentlich sollten Sie überprüfen, nur Dokument-Modus. Browser-Modell ist der erste parameter, der bestimmt, wie Dokument-Modus berechnet werden soll (standardmäßig). Also, wenn du korrekte Dokument-Modus, dann sollte alles wie erwartet funktionieren.
  • Die Funktion, die ich dachte, dass ich fehlte .querySelector() - nur verfügbar, wenn Dokument-Modus ist der IE8-standards oder höher. Ein kurzer test Hinzugefügt, um den html-bestätigt .querySelector ist auch verfügbar, wenn der browser-Modus ist die IE9 Kompatibilitätsansicht (IE8 die Kompatibilitätsansicht im IE8). <body> <script type="text/javascript"> var bodyEl = document.querySelector('body'); debugger; </script> </body>
InformationsquelleAutor jcairney | 2012-03-20
  1. 2

    Sei denn, jemand sagt etwas anderes, Orjoler der Kommentar darauf hin, dass alle Funktionen sind zur Verfügung gestellt basiert auf der Dokument-Modus, so gibt es keine Notwendigkeit, zu versuchen zu kontrollieren-browser-Modus, wenn Sie den Dokument-Modus Sie möchten.

    InformationsquelleAutor jcairney
  2. 0

    Ich lief in ein ähnliches Problem - Seite nicht gerendert wird korrekt in IE8/9, weil Display Intranetsites in Kompatibilitätsansicht war. Bitten Sie alle Benutzer zu deaktivieren oder zu Fragen für eine Gruppe Politik und hinzufügen von Ausnahmen für die ich weiß nicht, wie viele andere intranet-Seiten, dass dies keine option war.
    Der Dokument-Modus ist OK, Dank der X-UA-Compatible: IE=edge. Aber ich hatte immer noch die layout-Probleme.

    Ursache:
    Der Kompatibilität Modus bewirkt, dass IE zum senden von einem anderen user agent an den server. Für den IE8,9 ist, dass der IE7.
    Einige meiner ASP.NET Bibliotheken hat einige Prüfungen an, und macht die IE7-spezifisch, HTML/CSS, dass die Ergebnisse in layout-Fragen.

    Lösung:
    Ändern Sie die UserAgent string auf dem server auf "IE9 -" wenn Sie sagt, "IE7". Natürlich ist das eine schmutzige Lösung, da in der Theorie könnte es eine echte IE7-client.
    In meiner Sache (Intranet) ich weiß, dass meine Benutzer nur IE >= 8.
    Ändern der UserAgent erwies sich als schwieriger als erwartet. Ich habe Sie erfolgreich angewendet diese Idee - ableiten einer Unterklasse von HttpWorkerRequest und abfangen von Anforderungen für UserAgent. Diese indirekt überlastungen request.UserAgent und half das problem zu lösen.

    InformationsquelleAutor Piper
Schreibe einen Kommentar