IIS zeigt die Seite anders an, wenn localhost in URL vs. Hostname verwendet wird

8

Ich habe (noch ein) seltsames Problem mit IIS. Beim Anzeigen einer ASPX-Seite, die ich auf meinem lokalen Computer durch Navigieren zur http://localhost/page.aspxSeite entworfen habe, sieht sie wie erwartet aus (und sieht in IE, Firefox und Chrome gleich aus. Wenn ich localhostzur my_hostnameSeite wechsle , wird sie mit einer deaktivierten vertikalen Bildlaufleiste gerendert.

Das Verhalten wurde zum ersten Mal bemerkt, als ich meine Website auf unserem Live-Server veröffentlichte und die gleiche Diskrepanz feststellte. Nachdem ich meinen Kopf gegen die Wand geschlagen hatte, versuchte ich das, was ich oben beschrieben hatte und konnte mein "Problem" duplizieren. Damit wende ich mich an euch.

Dies wäre nicht wirklich ein Problem (abgesehen von der browserübergreifenden Inkonsistenz), außer dass dies eine "absolute" Position <div>vermasselt, die es teilweise vom Bildschirm wegbewegt, anstatt zentriert zu sein, wie es sein sollte (und wenn es anders betrachtet wird) außer im IE, wenn die Adresse alles andere als localhost ist).

Als weiteren Test habe ich meinem Projekt eine neue Aspx-Seite hinzugefügt und keinen der Standardcodes hinzugefügt oder geändert. Wenn ich mit localhost zur Seite navigiere, gibt es keine Bildlaufleiste. Wenn ich mit my_hostname zur Seite navigiere, wird die Bildlaufleiste angezeigt. Was auch immer der Unterschied ist, es führt dazu, dass die Verarbeitung von CSS durch den IE so durcheinander gerät, dass zunächst in allen Browsern, in denen ich teste, alles gleich funktioniert und der IE anschließend nur noch seine eigenen Regeln aufstellt. Das ist unglaublich frustrierend und ich hoffe wirklich, dass ich nur etwas falsch mache und es kein inhärentes Problem ist.

iis css

— maik
quelle

1

Ich konnte das CSS-Problem umgehen, indem ich meinen <div>Block aus dem Block herausbewegte und einen negativen Rand festlegte. Auf keinen Fall eine würdevolle Lösung, aber dies ist das Leben, wenn die Cross-Browser-Kompatibilität sichergestellt wird. Es wäre immer noch schön herauszufinden, warum es so anders ist.

— Maik

9

Ich weiß, dass dies ein alter Thread ist, aber ich habe gerade das gleiche Problem getroffen. Wenn Sie IE8 verwenden, liegt das Problem möglicherweise in der Kompatibilitätsansicht. Standardmäßig werden Sites in Ihrem lokalen Intranet - jedoch NICHT localhost - in der IE7-Kompatibilitätsansicht gerendert. Mehr Infos hier:

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

Leider hilft das nicht, die deaktivierte Bildlaufleiste loszuwerden, aber es erklärt die Diskrepanz.

— Claire
quelle

Das ist exzellent. Vielen Dank, dass Sie den Einblick in das Problem gefunden und veröffentlicht haben.

— Maik

1

Es scheint, dass IE9 das auch tut. Deaktivieren Sie im Dialogfeld "Einstellungen für Seite> Kompatibilitätsansicht" die Option "Intranetsites in der Kompatibilitätsansicht anzeigen", und es wird wie auf localhost gerendert.

— Mike Caron

7

Das Problem liegt in den Einstellungen der IE8-Kompatibilitätsansicht. Standardmäßig werden Intranetsites (Ihr Server) in der Kompatibilitätsansicht angezeigt. Um dieses Verhalten zu überschreiben, sollten Sie den folgenden Code zu Ihrem Code hinter Ihrer Aspx-Seite hinzufügen.

protected override void OnPreInit(EventArgs e) {
    Response.AddHeader("X-UA-Compatible", "IE=8");       

    base.OnPreInit(e);
}

Es hat bei mir funktioniert.

— Yaron
quelle

Dies geht direkt mit dem oben erwähnten Kompatibilitätsmaterial von Claire einher. Danke für diese Antwort!

— Maik

1

haha, ich habe gerade dieses Problem bekommen und war auf dem Weg hierher, um einen Beitrag zu schreiben, in dem ich dachte "Die Leute werden denken, ich bin verrückt". Tausend Dank!

— NullOrEmpty

Alternativ können Sie Response.AppendHeader("X-UA-Compatible", "IE=8");der Page_LoadMethode in Ihrer Site.master.csDatei hinzufügen .

— Nick Chammas

+1 Diese Lösung hat mir geholfen, mein Problem zu lösen, großartig !!

— Jemand

2

In IE9 werden Websites, auf localhostdenen ausgeführt wird, automatisch im Kompatibilitätsmodus gerendert. Gehen Sie folgendermaßen vor, um dieses (Standard-) Verhalten zu ändern:

Wenn nicht aktiviert, aktivieren Sie den Symbolleistenbefehl
Klicken Sie auf Seite> Einstellungen für den Kompatibilitätsmodus
Deaktivieren Sie "Intranetsites im Kompatibilitätsmodus anzeigen".

— Techek
quelle

1

Hier ist ein Beitrag auf StackOverflow dazu

Ändern Sie im Grunde den oberen Rand Ihres HTML-Layouts oder Ihrer MasterPage (nach dem <%@...%>) in:

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

— Serj Sagan
quelle

Das war eine große Hilfe!

— KFP

0

CSS sollte von der URL nicht betroffen sein. Gibt es eine Möglichkeit, dass Sie Text mit der URL irgendwo im Text versteckt haben, wodurch er verschoben wird? Wenn Sie die Quelle der Datei in beiden Situationen mit einem Tool wie http://www.quickdiff.com/ anzeigen , gibt es einen Unterschied zwischen ihnen?

— Scott Forsyth - MVP
quelle

Das ist genau der Gedanke, den ich hatte, weshalb das Problem der Logik zu trotzen scheint. Das einzige, was ich mir einfallen lassen kann, ist, dass IIS etwas Besonderes tut, je nachdem, ob die Anfrage von localhost kommt oder nicht. Wenn ich localhost, 127.0.01, meine IPv4-Adresse oder IPv6-Adresse verwende, wird diese wiedergegeben (ohne Bildlaufleiste usw.). Wenn ich den Hostnamen meines Computers verwende oder von einem anderen Computer aus darauf zugreife, wird er mit der Bildlaufleiste gerendert. Ich habe die Quelle zunächst mit meinen Augen untersucht und keine Unterschiede festgestellt und dies nur mithilfe von quickdiff.com überprüft. <3 IIS :(

— Maik

Auf jeden Fall seltsam. Wie wäre es mit einem QuickDiff auf den CSS-Dateien? Die andere Sache, die überprüft werden muss, ist Firebug oder Fiddler2, um festzustellen, ob die Header unterschiedlich sind. Das zeigt, was IIS in den Headern sendet.

— Scott Forsyth - MVP

Ein Teil meines Debuggens bestand darin, das kleine CSS, das ich hatte, stattdessen in die Aspx-Datei zu verschieben, sodass in dieser Abteilung nichts Besonderes vor sich geht. Ich werde Fiddler überprüfen und sehen, ob ich Unterschiede sehe.

— Maik

Fiddler zeigt Unterschiede in den Anforderungs- und Antwortheadern. Es sieht nicht nach etwas Spektakulärem aus, aber vielleicht trifft der IE eine Rendering-Entscheidung basierend auf etwas dort ... In den Anforderungsheadern besteht der einzige Unterschied darin, dass in den Anforderungsheadern my_hostname der Authorization-Header vor dem Host-Header steht, während er ist das Gegenteil in der localhost-Anfrage. In den Antwortheadern wird Persistent-Auth in my_hostname auf false und in localhost auf true gesetzt. Das in WWW-Authenticate codierte Token ist in my_hostname ebenfalls erheblich länger als in localhost, die Methode ist jedoch weiterhin Negotiate.

— Maik

Gibt es eine Chance, dass die Site im IE auf eine andere Zone eingestellt ist? dh mit einer URL ist es vertrauenswürdig und mit einer anderen nicht? Das würde allerdings nur den IE betreffen.

— Scott Forsyth - MVP

0

Das Update, dass @Claire auch für IE 11 gilt . Ich hatte Probleme, bei denen CSS beim Zugriff auf die Site über den Hostnamen des Servers nicht angewendet wurde, localhost jedoch einwandfrei angezeigt wurde.

Reparieren:

Internet Options -> Uncheck Display intranet sites in Compatibility View

Ich bin mir nicht sicher, warum localhost nicht als Intranetsite angesehen wird .

— Daniel Orlan
quelle

-1

Nur um festzustellen, dass ich ein ähnliches Problem wie das OP hatte und den von Serj Sagan vorgeschlagenen Code auf meine Site-Masterseite anwendete, aber IE = Edge in IE = 11 änderte. Jetzt, wenn veröffentlicht, wird alles so angezeigt, wie es sollte.

— Badvoc
quelle