IIS affichant la page différemment lorsque localhost est utilisé dans URL vs hostname

8

J'ai (encore un) autre problème étrange avec IIS. Lorsque vous affichez une page ASPX que j'ai conçue sur ma machine locale en naviguant vers http://localhost/page.aspxla page, cela ressemble à ce que vous attendiez (et a la même apparence dans IE, Firefox et Chrome. Si je passe localhostà my_hostnamela page, elle est rendue avec une barre de défilement verticale désactivée.

Le comportement a été remarqué pour la première fois lorsque j'ai publié mon site sur notre serveur en direct et j'ai constaté la même différence. Après avoir frappé ma tête contre le mur, j'ai essayé ce que j'ai décrit ci-dessus et j'ai pu reproduire mon "problème". Donc avec ça, je me tourne vers vous.

Ce ne serait pas vraiment un problème (sauf pour l'incohérence entre les navigateurs), sauf que cela fausse un positionnement "absolu" en le <div>déplaçant à mi-chemin de l'écran au lieu d'être centré comme il se doit (et est vu d'une autre manière sauf dans IE lorsque l'adresse est tout sauf localhost).

Comme autre test, j'ai ajouté une nouvelle page aspx à mon projet et je n'ai ajouté ou modifié aucun code par défaut. Si je navigue sur la page en utilisant localhost, il n'y a pas de barre de défilement. Si je navigue sur la page en utilisant my_hostname, la barre de défilement est là. Quelle que soit la différence, cela fait foirer le traitement de IE par CSS, au point que tout fonctionne au départ de la même manière dans tous les navigateurs dans lesquels je teste, et qu'IE crée ensuite ses propres règles. C'est incroyablement frustrant et j'espère vraiment que je fais juste quelque chose de mal et ce n'est pas un problème inhérent.

iis css

— maik
source

1

J'ai pu contourner le problème CSS en déplaçant <div>le bloc dans lequel il se trouvait et en définissant une marge négative. Ce n'est pas un correctif gracieux, mais c'est la vie en garantissant la compatibilité entre les navigateurs. Ce serait quand même bien de comprendre pourquoi c'est si différent.

— maik

9

Je sais que c'est un vieux fil, mais je viens de rencontrer le même problème. Si vous utilisez IE8, le problème peut être sa vue de compatibilité. Par défaut, les sites de votre intranet local - mais PAS l'hôte local - sont affichés dans la vue de compatibilité IE7. Plus d'infos ici:

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

Malheureusement, cela n'aide pas à se débarrasser de la barre de défilement désactivée, mais cela explique la différence.

— Claire
source

C'est excellent. Merci d'avoir trouvé et publié les informations sur le problème.

— maik

1

Il semble qu'IE9 le fasse également. Dans la boîte de dialogue Paramètres de la vue de compatibilité, décochez la case "Afficher les sites intranet dans la vue de compatibilité" et le rendu s'affichera comme sur l'hôte local.

— Mike Caron

7

Le problème réside dans les paramètres d'affichage de compatibilité IE8. Par défaut, les sites intranet (votre serveur) sont affichés dans la vue de compatibilité. Pour remplacer ce comportement, vous devez ajouter le code suivant à votre code derrière votre page aspx.

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

    base.OnPreInit(e);
}

Ça a marché pour moi.

— Yaron
source

Cela va de pair avec les éléments de compatibilité mentionnés par Claire ci-dessus. Merci pour cette réponse!

— maik

1

haha Je viens de recevoir ce problème, et je me dirigeais ici pour mettre un post en pensant que "les gens vont penser que je suis fou". Mille mercis!

— NullOrEmpty

Alternativement, vous pouvez ajouter Response.AppendHeader("X-UA-Compatible", "IE=8");à la Page_Loadméthode dans votre Site.master.csfichier.

— Nick Chammas

+1 Cette solution m'a aidé à résoudre mon même problème, génial !!

— Quelqu'un

2

Dans IE9, les sites fonctionnant sur localhostsont automatiquement rendus en mode Compability. Pour modifier ce comportement (par défaut), procédez comme suit:

S'il n'est pas activé, activez la commande de la barre d'outils
Cliquez sur Page> Paramètres du mode de compatibilité
Décochez "Afficher les intranetsites en mode de compatibilité"

— Techek
source

1

Voici un article sur StackOverflow à ce sujet

changer fondamentalement le haut de votre mise en page HTML ou MasterPage (après le <%@...%>) pour:

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

— Serj Sagan
source

Ce fut une énorme aide!

— KFP

0

CSS ne devrait pas être affecté par l'URL. Y a-t-il une chance que vous ayez caché du texte avec l'URL quelque part dans le corps qui le fait se déplacer? Si vous affichez la source du fichier dans les deux situations à l'aide d'un outil comme http://www.quickdiff.com/ , y a-t-il quelque chose de différent entre eux?

— Scott Forsyth - MVP
source

C'est exactement la pensée que j'ai eue, c'est pourquoi le problème semble défier la logique. La seule chose que je peux trouver, c'est que IIS fait quelque chose de spécial selon que la demande provient de localhost ou non. Si j'utilise localhost, 127.0.01, mon adresse IPv4 ou IPv6, elle est la même (sans barre de défilement, etc.). Si j'utilise le nom d'hôte de mon ordinateur ou y accède à partir d'un autre ordinateur, il s'affiche avec la barre de défilement. J'ai d'abord examiné la source avec mes yeux et je n'ai vu aucune différence, et j'ai simplement vérifié cela en utilisant quickdiff.com. <3 IIS :(

— maik

Certainement étrange. Que diriez-vous d'un quickdiff sur les fichiers CSS? L'autre chose à vérifier est firebug ou fiddler2 pour voir si les en-têtes sont différents. Cela montrera ce que IIS envoie dans les en-têtes.

— Scott Forsyth - MVP

Une partie de mon débogage consistait à déplacer le peu de CSS que j'avais dans le fichier aspx, il n'y a donc rien de spécial dans ce département. Je vais vérifier Fiddler et voir si je peux voir des différences.

— maik

Fiddler montre des différences dans les en-têtes de demande et de réponse. Cela ne ressemble à rien de spectaculaire, mais peut-être qu'IE prend une décision de rendu basée sur quelque chose là-bas ... Dans les en-têtes de demande, la seule différence est que dans les en-têtes de demande my_hostname, l'en-tête d'autorisation vient avant l'en-tête Host alors l'inverse dans la demande localhost. Dans les en-têtes de réponse, Persistent-Auth a la valeur false dans my_hostname et true dans localhost. Le jeton encodé dans WWW-Authenticate est également beaucoup plus long dans my_hostname que localhost, mais la méthode est toujours Negotiate.

— maik

Y a-t-il une chance que dans IE le site soit défini sur une zone différente? c'est-à-dire avec une URL en laquelle il a confiance et avec une autre non? Cela n'affecterait que IE cependant.

— Scott Forsyth - MVP

0

Le correctif que @Claire applique également à IE 11 . J'avais des problèmes où css n'était pas appliqué lors de l'accès au site via le nom d'hôte du serveur, mais localhost affiché correctement.

Pour corriger:

Internet Options -> Uncheck Display intranet sites in Compatibility View

Je ne sais pas pourquoi localhost n'est pas considéré comme un site intranet .

— Daniel Orlan
source

-1

Juste pour dire que j'avais un problème similaire à celui de l'OP et que j'appliquais le code suggéré par Serj Sagan à la page principale de mon site, mais que j'ai changé IE = Edge en IE = 11, maintenant, lorsqu'il est publié, tout s'affiche comme il se doit.

— Badvoc
source