J'ai un serveur NodeJS en cours d'exécution sur ma machine locale à des fins de développement. Par défaut, il utilise le port 1337. (J'ai essayé une poignée d'autres ports tels que 8080, 1234, 9000, 9090, 65432 et al).
Je peux me connecter avec succès à ce serveur NodeJS à partir de Chrome, Firefox et Opera. Mais, lorsque j'essaye de me connecter avec Internet Explorer 11, je vois "Cette page ne peut pas être affichée" (voir image).
J'ai essayé diverses "solutions" et j'ai consulté plusieurs questions / réponses sur ce site. Aucun d'eux n'a fonctionné. Comprenant:
- J'ai essayé 127.0.0.1
- J'ai désactivé le "Mode protégé" et le "Mode de protection amélioré".
- J'ai ajouté "localhost" à la zone intranet et à la zone de confiance.
- J'ai désactivé les "Messages HTTP conviviaux" en espérant voir plus de détails.
- J'ai essayé d'utiliser le nom de mon ordinateur et le nom DNS.
- J'ai essayé de créer une entrée manuelle dans mon fichier d'hôtes pour "localhost" et même "thisismyfrigginpc" en utilisant mon adresse IPv4.
Le seul succès que j'ai eu, c'est lorsque le serveur fonctionne sur le port 80 ( http://localhost:80/ou http://localhost). Cependant, je ne peux pas développer sur le port 80 pour diverses raisons. J'ai besoin de tester mon code sur le port localhost + (certains ports, tout port autre que 80 et 443).
Questions et réponses qui n'aident pas:
- Pourquoi je ne peux pas visiter http: // localhost via IE?
- Chrome et Firefox peuvent atteindre localhost; Internet Explorer 9 ne peut pas. Pourquoi?
- Comment tester des sites locaux dans Metro IE10?
- /programming/19268956/can-not-access-localhostport
Veuillez aider!
BTW, exécutant Windows 7 Enterprise 64 bits. Déploiement d'entreprise, mais j'ai des droits d'administrateur. La configuration du réseau est un DHCP assez standard sans NAT ni proxy.
MISE À JOUR
Sur recommandation de @codenoire, j'ai installé Fiddler pour voir la demande / réponse. Vous trouverez ci-dessous la demande et la réponse brutes d'IE-à-Fiddler-au-serveur-à-Fiddler:
Demande
GET http://localhost:1337/common/test.html HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: localhost:1337
Réponse
HTTP/1.1 200 OK
Set-Cookie: _session=WRuVLmrXMtjnDJY8;expires=Wed, 15 Jan 2014 23:19:16 GMT;path=/;domain=;httponly
Content-Type: text/html;charset=utf-8
Last-Modified: 1389818856000
Date: Wed, 15 Jan 2014 22:19:16 GMT
Connection: keep-alive
Content-Length: 128
<html>
<head>
<title>Connectivity Test Page</title>
</head>
<body>
<h1>This is a test page.</h1>
</body>
</html>
Résultat
Mise à jour 2014-01-17
J'ai testé ce scénario sur des installations Windows 7 «propres» hors entreprise avec IE 11. Les résultats sont identiques à mes observations permanentes. Cela signifie que toute configuration effectuée par une image d'entreprise de Windows peut être éliminée en tant que cause. De plus, la configuration du réseau est assez "vanille".
Mise à jour 2014-01-21
J'ai essayé les idées "d'émulation" d'Internet Explorer. J'ai créé une clé, "iexplorer.exe" en tant que valeurs DWORD et QWORD (individuellement) avec les valeurs 8000, 8001, 9000, 9001, 10000, and 10001. Après chacun, redémarré et testé à nouveau. Toutes ces tentatives ont produit les mêmes résultats. Soit dit en passant, nous devons tester ce code dans IE11. Les divers codes et astuces de compatibilité ne nous aident pas à long terme.
Mise à jour 2014-01-22
Démarrage d'un serveur XAMPP Apache sur le port 1337. IE s'y connecte très bien. Donc, il y a quelque chose dans la réponse NodeJS que IE n'aime pas et les autres navigateurs semblent bien gérer. Nous allons enquêter sur notre code NodeJS pour voir ce qui se passe exactement dans les en-têtes / contenus pour voir si quelque chose est hors ligne.
Mise à jour 2014-01-27: Résolution
Je voulais juste documenter les résultats. La réponse d'origine comprenait Content-Type: text/html;charset=utf-8et basée sur la bonne réponse, elle devrait être: Content-Type: text/html; charset=utf-8avec un espace entre le type et le jeu de caractères.
Voici les résultats:
Réponse brute:
HTTP/1.1 200 OK
Set-Cookie: _session=EshWS7xDnCeV9pXS;expires=Mon, 27 Jan 2014 18:49:21 GMT;path=/;domain=;httponly
Date: Mon, 27 Jan 2014 17:49:21 GMT
Last-Modified: 1389818856000
Content-Type: text/html; charset=UTF-8
Content-Length: 128
Connection: keep-alive
<html>
<head>
<title>Connectivity Test Page</title>
</head>
<body>
<h1>This is a test page.</h1>
</body>
</html>
Merci à @harrymc d'avoir découvert la réponse.
la source
Réponses:
L'article WWW3 Définition du paramètre de jeu de caractères HTTP spécifie:
Cela définit
Content-Typecomme ayant un blanc avantcharset.Je sais que vous avez déjà découvert que c'est effectivement le problème, donc la source du problème est une programmation très peu imaginative de Microsoft ou d'un proxy intermédiaire.
la source
Il y a probablement un problème dans vos paramètres pour IE.
Le moyen le plus simple de résoudre ce problème serait d'ouvrir les Options Internet, d'accéder à l'onglet Avancé et de cliquer sur "Réinitialiser les paramètres d'Internet Explorer". Assurez-vous de choisir cela et non de "Réinitialiser les paramètres avancés", car celui-ci ne comprend pas TOUS les paramètres.
Si cela ne fonctionne pas, essayez également de naviguer en utilisant 127.0.0.1 au lieu de localhost. Cela ne résoudra probablement pas le problème, mais pourrait parfois créer un problème.
Edit: je voulais ajouter que cela pourrait être un problème avec IE11. Je sais que nous avons eu beaucoup de problèmes de compatibilité avec elle. Si vous ne souhaitez pas revenir à IE10 et essayer cela, vous pouvez toujours émuler à partir du registre:
En dessous de
HKLM\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\vous allez créer une clé appelée:
et à l'intérieur, créez une valeur DWORD:
avec une valeur de l'un des éléments suivants:
Nous avons eu le plus de succès avec 10001.
la source
Vérifiez vos paramètres de proxy. Étant donné que vous êtes sur un réseau d'entreprise, quelqu'un peut avoir une politique de proxy inadéquate insérée dans votre IE (qui ne reflétera pas nécessairement les autres navigateurs).
la source
Je fais ces changements, et tout fonctionne bien sur Windows 10 64 bits.
la source