Like a lot of programmers, I test sites locally.
I use the hosts file to map domain names to my local ip (127.0.0.1).
I use qualified domain names, usually with a "d" subdomain (for "development").
For example:
d.somewebsite.com
d.anotherwebsite.com
and so on...
In Microsoft edge, most of the web sites work. However, a couple of them do not. There is nothing special or weird about the domain names that won't work. Just a simple d.someletters.com.
They work fine in Chrome, IE, and Firefox.
In Edge, I get the error message:
"Hmm, we can't reach this page."
At first I thought it wasn't resolving the IP. However, I realized when I made a typo on another non-related url, that requests which are not routed by the hosts file are sent to my ISP to be resolved. If my ISP can't resolve it, they send back this special search results page with suggestions of what you might be trying to find. Well, when I go to my local domain, I do not get this page from my ISP. I get the error mentioned above straight from edge.
So, it seems to me that Edge is resolving the domain correctly, otherwise it would have been sent off to my ISP's DNS.
So, I would think then that maybe Edge just can't connect to the local machine. But like I said, several of these local domains are working fine. Also, using 127.0.0.1 directly in Edge also works. It's just these couple of domain names giving me a problem. And only in Edge (all other browsers work) Any ideas?
The web server is Apache2 for Windows (xampp) if that matters.
Also, if I open the debug window in Edge and monitor the network, I do not see any requests going out at all.
EDIT: I am no longer using the hosts file. I have dnsmasq running on one of my Linux boxes and I am using it for DNS instead of hosts. Also no longer using loopback (obviously since DNS is on another box now), I am using an internal private ip address (192.168...). Same issue.
Your network can block loopback as a security measure in Windows 10.
Open a command prompt as administrator, and run this to exempt Edge from a loopback:
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
(Microsoft.MicrosoftEdge_8wekyb3d8bbwe is the identifier for the Edge app)
There's a blog post here giving more detail:
https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
I (thought I) solved it!
Things that did not work:
Making changes to IE compatibility settings or Windows compatibility lists
Using fully qualified domain names
Using an IP address other than loopback
using http vs https
remove all javascript and cross-site scripts/resources from the web page
checking / unchecking the option in about:flags for allowing localhost loopback or using compatibility settings
removing / adding / editing the entries in the TabProcConfig of the Windows Registry
deleting browsing history, cache, cookies
The Solution: in a complete counter-intuitive twist:
Remove the domain names from your trusted sites list!
Open the Internet Options dialog (just ask Cortana or use windowskey+s)
Go to the Security tab
Click on the Trusted Sites zone
Click the Sites button
Remove the troubled domain names from the trusted sites list
Click Apply and then close the dialog
Open Edge (or restart it if it is already running)
Viola
I should note that I, using common-sense, figured that it wasn't just the fact that the site was merely present in the "Trusted Sites" zone that caused the issue. I figured it was some setting on that zone. So, before I deleted the domain names from the "sites" list, I made all of the settings match my Internet Zone settings exactly (Medium high security, enable protected mode, do not require server verification for all sites), and I also tried every other combination I could find. There was no combination of zone security settings that worked. The only solution was to simply remove the domains from the Trusted Sites list completely. Funny thing is that it works in IE regardless, even though this is the internet settings dialog for IE. This only seems to affect Edge.
EDIT:
Two weeks later I change my configuration to, instead of the hosts file, use dnsmasq on a local Linux machine and using it for DNS. I'm not sure if it happened right away but at some point Edge stopped working again! I already had the "allow loopback" checkbox checked in about:flags, so I didn't expect the CheckNetIsolation fix to work. But, it did. Edge version is 20.10240.16384.0. I used the fix from Can't open localhost in Microsoft Edge (Project Spartan) in Windows 10 preview
EDIT #2
A couple of months later and Edge is having this problem again. I tried both previous solutions (and others) and neither of them work for me anymore.
I'm leaving this answer because I am assuming I experienced two separate problems.
Edge doesn't support VPN IP addresses so any workaround needs to employ some sort of proxy. Here are some solutions that I found work:
Install and run fiddler. Fiddler will basically intercept the request from the browser then forward it to the destination. This is the easiest workaround.
Configure a proxy via the built-in Windows tool: netsh. The basic steps involve assigning your development domain to an available local private IP address in the 127.0.0.0/8 range, then mapping this IP to the webserver's IP on the VPN. See step by step instructions here
Use the port forwarding feature of ssh to configure a proxy. Assuming that port 80 is available on localhost, add 127.0.0.1 d.somewebsite.com to your host file, then run the following ssh command: ssh -L localhost:80:localhost:80 user#devwebserver, where devwebserver is the hostname of your development webserver (say in the VM or vagrant instance, or across the VPN). This option assumes you have ssh access to the dev server.
Your "remove from trusted sites" solution didn't work for me because my local sites were not on my trusted sites.
But you got me looking the Internet Options and I managed to get IIS working for local sites for me on Windows 10. This is what I did:
Open Internet Options and select "Local intranet"
Click on "Sites"
Click on "Automatically detect intranet network"
Click OK. Try your local machine site in Microsoft Edge and it should now work.
May not apply to your situation, but nonetheless. My setup was as follows. A public space address (internet) page was attempting to load a page with a private space address (intranet) in an iframe and Edge would refuse to load the intranet page with the same "Hmm, we can't reach this page" message, and with "SEC7117 Error" in the debug console. Turns out Edge doesn't like mixing internet/intranet zones (see Understanding Enhanced Protected Mode blog post for reasons why). Edge runs tabs in separate AppContainers, and AppContainer network restrictions are sensitive to your network configuration.
My solution was to take the server which hosted the intranet page in question out of the domain network by assigning a second private space IP to it, and create a second DNS entry to that IP. The server ends up having 2 IPs: one on the domain network and an alternative one and 2 different DNS entries. Edge is then pointed to the alternative URL and it starts loading the intranet page just fine. It seems like as long as the IP masks of the PC and the page URL in question do not match, Edge will load the page.
The blog post I mentioned has info on Loopback-blocked for localhost and lack of privateNetworkClientServer capability in IE. As far as I can tell all that info applies to Edge.
When this happens to me I can find a domain entry in the registry key below that matches the domain. When I remove it things work, for a while... I don't know why but Edge will add it back eventually.
Computer\HKEY_USERS\S-1-5-21-964789662-521690395-1734141374-1111\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TabProcConfig
Noting from your edit that you are now accessing the site on 192.168.0.0/16 address, rather than on 127.0.0.1, I am guessing you are running into an issue with the way the Edge browser behaves differently depending on the interface used to access the site. Other browsers I tried don't behave this way.
In my environment, I had a Virtualbox host-only network setup and this had an NdisDeviceType of 1. Edge would only allow me to navigate to sites over this interface after I changed NdisDeviceType to 0. The registry key you need is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\XXXX
Instead of XXXX, you need the correct key for your interface, which I determined from "route print" and subtracted 1. For me it was "0016".
The value to change is called *NdisDeviceType. (That's a literal asterisk.) I changed it from 0 to 1 and had to reboot for Windows to notice the change.
My answer was gleaned from a post by "Jani L" dated Oct 3, 2017. I also posted this solution in more detail to another stackoverflow question. Also see a Virtualbox ticket 15565.
None of the other solutions worked for me. It turns out that my issue relates to VPN. Microsoft Edge still doesn't support VPN IP addresses, while Internet Explorer 11 does. Impressive that this is still an issue as of May 2016.
Additional Details:
https://social.technet.microsoft.com/Forums/en-US/b3a687ae-345d-4c3f-9070-184b33fb1fc6/microsoft-edge-cant-access-vpn-ip-address-but-ie-11-can?forum=win10itprogeneral
Currently Microsoft Edge seems to be not working well with VPN. And the mechanism to connect to Internet from Microsoft Edge is a little different from Internet Explorer 11 and the other desktop browsers, which I can't explain clearly as I don't know much about it.
So based on the current situation, please take use of Internet Explorer 11 instead.
In my case changing the network type from private to public did the trick. This is also reproducible and changing the network type reliable changes the state from "working" to getting: Http failure response for (unknown url): 0 Unknown Error
For me, I went to Internet Options (control panel), then Security, then selected local intranet and then put a tick in the "Automatically detect intranet network". This greyed out the nested options below, and Edge immediately started using my hosts file.
Related
This problem has a very simple (almost silly) fix, but it took me 2 hours to discover today, and none of my searches gave the answer, so I am posting this along with the answer to help others.
I have a website set up in IIS to run locally, which has worked in the past.
The URL is like: http://localhost/mywebsite
But today when I tried to open the site, it did not work in any of my browsers (IE, Chrome, and Firefox).
Even the main IIS Welcome page at http://localhost was not working.
Internet Explorer showed: "Can't reach this page / Make sure the web
address http://localhost is correct". Under "More information", it
showed "There was a temporary DNS error. Try refreshing the page.
Error Code: INET_E_RESOURCE_NOT_FOUND"
Firefox showed: "Unable to connect / Firefox can't establish a
connection to the server at localhost."
Chrome showed: "This site
can't be reached / localhost refused to connect /
ERR_CONNECTION_REFUSED"
Neither restarting the server in IIS, nor calling iisreset from a command prompt fixed it.
I compared my "hosts" file to another computer which was not having the problem. Both had the same entry for "127.0.0.1 localhost".
I checked the Services panel and verified that "World Wide Web Publishing Services" was running.
I ran "netstat -a". It showed nothing listening on port 80, but I didn't know what was causing that.
Based on suggestions I found while searching for a solution, I tried the following, none of which fixed the problem:
I turned off User Account Control.
In IIS, I updated the Site Bindings for "Default Web Site" to change the port number from 80 to a different value, 8085. The site did not load with the new port number either.
In case something in IIS had gotten corrupted or messed up, I used "Turn Windows features on or off" to turn off all the features for Internet Information Services.
Then after rebooting, I turned them all on again and rebooted again.
I still had the same problem.
What else could be causing IIS and my local website not to work?
Make sure the website has been started in IIS:
In the left pane of IIS Manager under "Sites", select the appropriate site. If your site is configured under the "Default Web Site", select that one.
In the right pane under "Manage Website", there are "Start" and "Stop" links.
When the website is running, the Start icon (arrow) will be gray and its link will be disabled; the Stop icon (square) will be black and its link will be enabled.
When the website is NOT running, the Start arrow will be green and enabled; the Stop icon will be gray and disabled.
So if the Start link has a Green arrow by it, that means the website is NOT running, and you need to click to start it.
By default, web sites are started automatically when IIS is started or restarted.
But if you click the link to stop the site, it will remain stopped even after you reboot the computer or restart IIS. It won't be restarted until you click Start again.
I had also this situation where a local website hosted by IIS did not work. My site was already started but it seemed to lack the rights for an internet browser to access to the local site.
In my case I got the site working by giving the site's root folder (and its contents in the Windows 10 file system) the following usage rights:
Authenticated Users
This usage right can be set in folder properties and its security tab.
Other usage rights present are:
SYSTEM
My own account
Adminstrators (MACHINENAME\Admistrators)
I post this solution here in case someone is in trouble with the same issue.
An update: This 'Authenticated Users' group needs also permission to modify files and folders in case e.g. Wordpress is used as a local site and the adminstrator wants to e.g. update themes and plugins of the site.
If this permission is not set, Wordpress will fail to write the updates to the local folder. The message shown is: "Installation Failed: Could Not Create Directory".
However, please note that at the moment I cannot guarantee that these settings are completely safe and do not compromise your system for attackers etc. But I've taken the risk myself, and the settings will provide a working environment to develop locally.
some time this problem because the application pools is stopped after restart server machine this is problem happened me.Picture for clarification, enter image description here
I encountered this issue recently, and none of the other answers here helped me. I was unable to connect with http://localhost/mywebsite, but I could with http://127.0.0.1/mywebsite. I was able to put a bandaid on the issue by creating a new binding:
Type: https
IP address: All Unassigned
Port: 443
Host name: empty
[x] Disable Legacy TLS
SSL certificate: IIS Express Development Certificate
I could then connect with https://localhost/mywebsite. Hopefully this helps someone else!
DNS Unlocker version 1.4 is an application which is automatically installing itself into my windows without administrative permissions.
What it does it hacks all my browsers and show ads on every page causes redirection to malicious websites and slows down my PC.
Other special thing it changes the Preferred DNS IP address to something else.
I have tired a lot methods to remove it form system but I couldn't succeed yet.
DNS Unlocker installs a service in your computer Named as "DNS Client" which starts automatically.
Solution: Just disable it from you Local services you'll get rid from all this browser attacks.
After investigating, I found out that the damn "DNS Unlocker" had modified my DNS settings! After fixing this I was completely good! I have google chrome, so I am unsure if this fix persist to other browsers.
The path to do this follows:
Control Panel > Network and Internet > Network and Sharing Center > Change Adapter Settings > Right-click your active internet connection (usually Wi-Fi since everyone uses that, unless your using a desktop) and click properties > Now under the Networking tab, scroll down until you find Internet Protocol Version 4 (TCP/IPv4) > Highlight that then click on properties > Both options in this windows should be automatic! The first option should be set to "Obtain an IP address automatically" and the second should be set to "Obtain DNS server address automatically!" If your computer belongs to a company or you actually have a custom DNS then this would not apply to you. Once you are finish, click "OK" and close the windows > Now go back into Chrome and reset your settings one more time and boom! It should work just fine.
"Ads by DNSUnlocker" is a browser based virus, I solved this issue on my windows 7 by Removing unwanted DNS entries from internet connection(in Windows 7, right click on the network icon(right-bottom corner on screen)-> Network and Sharing Center -> internet connection(Local Area Network link -> Properties -> IPv4 -> Properties)
select "Obtain DNS server address automatically" and click "Advanced"->DNS -> remove ip addresses if any on the DNS server addresses box.
I have a Java web application in domain A (that we control). This application displays another website located in domain B (which we do not control) in an iframe. This external website was recently updated to require users to log on before they can see content. They provided us with a URL that will automatically log our users into their site. This URL works when we navigate directly to it in Internet Explorer (we get automatically logged in etc).
However, apparently there was an update to Internet Explorer so that cross domain communication is not allowed. So now when the login URL is displayed in the iframe, it does not successfully log on (I am guessing its being blocked from creating security cookies).
Also, if we browse to the URL directly and get the security in place, then any iframe elements of the site will not work (I am guessing it is being blocked from accessing security cookies).
Does anyone know of a work around for this? Changing the security level on Internet Explorer is not an option (it is controlled by our company's system administrator). Internet Explorer is also our company standard, so we cannot change that (even though it works fine in Firefox).
When you say "elements of the site will not work" what precisely does that mean?
"Cross-domain" interactions have always been restricted in all browsers. This is called "same-origin-policy" and it's the foundation of web security. The "update" to Internet Explorer you're referring to restricts IE such that a webpage on Domain A can no longer navigate a subframe that is inside a page from Domain B. That restriction has been present in IE for 7+ years and is in all browsers. This restriction is not causing your problem.
This most likely problem here is that the subframe fails to set a P3P header that would permit its cookies to be stored. There are perhaps 30 duplicates on that issue on StackOverflow.
To determine if this is what you're encountering, try this:
In IE, click Tools > Internet Options > Privacy tab.
Set the slider to Accept all
Clear your cookies
Restart the browser and retry the scenario.
If this change solves the problem, then the fix is easy: configure the page which is being framed to specify its cookie policy using a P3P response header.
If this doesn't solve the problem, please update the question with more information that would allow others to reproduce it (e.g. traffic logs, live site URL, etc).
It turns out that this was causes by the login site not being on the trusted sites list. Having security add it as a trusted site and pushing that to all company computers solved the issue.
I have setup a brand new Orchard CMS 1.5.1 site using Web Platform Installer on Windows 2008 Server. I wanted to test out the Performance settings so I configured the following Warmup entries one per line:
/
/blog
...and checked the following options:
x Generate warmup pages periodically 90 Every minutes
x Generate warmup pages any time some content is published
When I visit the site the performance was still a bit slow. The Performance Warmup settings show each page has a status of zero and a red "down arrow" icon next to it.
Is there anything else I need to enable? Is there anything I am missing in the configuration like permissions, etc.
UPDATE:
I have noticed that my site does not have a folder to store the warm up pages. I added that folder manually but it still didn't fix my problems. Are there permissions I would need to set on that folder?
UPDATE 2:
After talking with Sebastien Ros, I think I understand what is wrong but still don't know how to fix it. The base URL setting in Orchard is set to "www.mydomain.com" as it should be but networking-wise my server does not allow my site to go out to the internet and query itself by that address in order to generate the warm-up page. To make matters worse, I have several sites that are hosted on the same IP address and using host headers to distinguish between sites. This prevents me from even being able to configure the base URL as a local IP address (which cause issues with other modules anyway).
Not sure what alternatives I have now.
Thanks,
Brian
Make sure that the general settings page is pointing to your base URL, i.e. http://mywebsite.com.
It may be pointing to the local host by default.
I confirmed with a Network Engineer at my server host that there was a networking restriction on outgoing requests coming back in for the web site. So, the performance module could not query www.mydomain.com and get an answer. Once the network restriction was removed, I was able see Warm-ups create the cache pages with a Status 200.
Alternatively, it was suggested that I create entries in my host file for each of my Orchard sites. I did not try this but I see no reason why it would not work even with the host-headered scenario that I have.
Brian
A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.