Wir haben eine Ruby on Rails-Anwendung entwickelt. Wir haben diese Anwendung kürzlich hinter einem Apache-Proxy neu implementiert, der HTTPS verwendet.
Nachdem wir dies getan haben, wird einer unserer Nutzer auf die folgende Seite geschickt, wenn er versucht, die App zu benutzen: Ссылка , das sagt:
%Vor% Weiß jemand, unter welchen Umständen IE behaupten würde, nicht zu wissen, was mit einer text/javascript -Datei zu tun ist? Es ist nur dieser eine Benutzer so weit.
Windows 7 / IE 8 und XPsp2 / IE8
EDIT Hinzufügen der vollständigen HTTP-Antwort, die IE auf
setzt %Vor%Ok. Sieht so aus, als hätten wir es herausgefunden. Es war ein Fehler in unserer Anwendung, der dazu führte, dass er ein ungültiges JavaScript an den Browser schickte. Es scheint, dass Rails Weiterleitungen von nicht authentifizierten Sitzungen auf die Anmeldeseite behandelt, indem er ein kleines JS-Fragment sendet, das folgendermaßen aussieht:
%Vor%Wir hatten einen Tippfehler im ERB für diese Datei, die es stattdessen gesendet hat:
%Vor%Interessant ist, dass nur einige Versionen von IE dadurch verwirrt werden.
IE sollte Text / Javascript erkennen (siehe zum Beispiel , dort wird" text / javascript "erwähnt). Andere Faktoren müssen im Spiel sein. Sie können versuchen:
(1) Sie können den Typ direkt im Script-Tag angeben
%Vor%(2) Kommt das Javascript von derselben Seite mit demselben Protokoll? Der Benutzer kann Inhalte blockieren, die nicht abgesichert sind, wenn er von einer ungesicherten Adresse kommt, und der IE erhält möglicherweise nur eine irreführende Fehlermeldung.
(3) Weil Sie sich jetzt hinter dem Apache befinden, gibt es irgendwelche anderen Header, die den IE verwirren könnten?
(4) Ich wette, Sie haben überprüft, dass Rails den richtigen Speicherort für Ressourcen (d. h. es verwendet den Proxy-Host, Apache, nicht Schienen).
Mein Verdacht ist, dass Ihr Javascript-Inhalt entweder nicht korrekt ist oder einfach nicht "IE" korrekt ist. : -)
Vor allem, wenn Sie sagen, seine UTF-8 sind Sie sicher, dass das ist, was Sie servieren? Entwerfen Sie entsprechend der Empfehlung von Brad die Zeichensatzdefinition und sehen Sie, ob sich das Verhalten ändert.
Nehmen Sie auch eine Kopie des zurückgegebenen Javascript und versuchen Sie es irgendwo zu validieren. Ich habe gesehen, dass andere Probleme melden, bei denen das Javascript auf bestimmte Arten beschädigt wurde, die nur bestimmte IE-Versionen zum Absturz brachten. Verketteln Sie mehrere js-Dateien oder ähnliches? Ein anderes Beispiel ist ein versehentliches% & gt; Tag in Ihrer Javascript-Datei wird einige Browser verwirren.
Indem Sie die zurückgegebene Wert-Client-Seite mit Hilfe von Firebug- oder Chrome-Entwicklertools greifen, können Sie sicher sein, dass der Proxy die Header oder die Kodierung (einschließlich gzip) nicht vermasselt.
Ich habe auch gehört, dass bestimmte ältere Versionen von IE MIME-Typen in Iframes nicht richtig behandeln. Benutzt du überhaupt einen iframe?
Zu guter Letzt ändert eine Antiviren- / Sicherheitssoftware die Kopfzeilen der ausgehenden Anfrage Accept (nicht sehr nett?), die den Server dazu bringen zu glauben, dass der Browser gzip oder sowas nicht unterstützt. Können Sie sich eine Kopie der ausgehenden Anfrage für das Javascript holen? Sie möchten nach geänderten Anforderungsheadern suchen.
Sie können das type -Attribut des script -Tags löschen. HTML5 benötigt es nicht, und alle Browser verstehen es als "ihren lokalen Geschmack von JavaScript", was Sie wollen. Ihre Seite wird nicht gegen den HTML4-Doctyp validiert, aber solange Sie wissen, warum sie nicht validiert wird, finde ich das in Ordnung. Wichtiger zu arbeiten als zu validieren.
Tags und Links javascript internet-explorer