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.
I inherited a mess of servers which host multiple applications on IIS6, protected by R6 SiteMinder. The environment is soon going to R12, and we have also received some new servers with IIS7.5. (Lots of change, all within the next 60days.)
I am not an expert, and so am having trouble with some of the more detailed steps of configuration. Thus far, on the new server I am able to create and apply SiteMinder to the DefaultWebSite (and everything contained within), and any custom Sites that I create. Unfortunately in our environment, it is already set up with a handful of applications that live underneath DefaultWebSite, only some of which we desire SiteMinder protection.
In IIS6 I was able to simply add a site to SiteMinder authentication by applying the ISAPI6WebAgent.dll in the wildcard mappings. In IIS7.5, this does not seem to work. I follow the specific details in the installation manual and it seems like it is either an all-or-nothing situation: everything under DefaultWebSite is protected, or nothing is.
This will cause a SIGNIFICANT amount of additional work in my environment (and it also means upgrading in place is not possible, so all applications that require SiteMinder authentication will need to be migrated in the next 60 days.) Is there ANY workaround for this? Google has not provided me with any solutions, and my SiteMinder team is claiming "it is no longer possible with IIS7.5" to keep the environment the way it is currently set up.
Any and all help appreciated.
For those that care, if you are running under an Integrated App Pool, you can simply add and remove the SiteMinder modules to control which sites are protected by SiteMinder. This DOES work on apps below a virtual directory - and using the config files you can both inherit protection by default, or have it unprotected and add it later by simply "Configure Native Module" and adding it back.
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
It looks like my server has ASP disabled because when trying to view an ASP file its source code is shown in the browser. After doing some research I've heard I can enable ASP on my server using IIS - is this correct? I've set up my website in IIS as far as I could; it's not asked me for FTP details or anything so I don't know how it's going to 'install ASP'... I've enabled ASP via the Control Panel so it appears within IIS, but don't know where to go next. Am I headed in the right direction?, could anyone give me some advice as I'm not sure if I'm barking up the right tree. Many thanks in advance.
I just tried this on my Windows 7 Professional box. Once I added the feature using "Add Windows Features", and refreshed IIS Manager, Classic ASP just showed up in the handler mappings.
Make sure Enable Parent Path = true in behavior Section of ASP in IIS.
Go into your programs > windows features. Find IIS, and go to www services. You should see ASP there. You may have to enable it in IIS as well - you haven't mentioned what version of IIS you're using (or OS), so I'll leave that up to you.
I want to enable HttpCompression in IIS6.0 using adsutil.vbs. I understand that i can enable it for generic server level as well as for a specific website under IIS. (I used this http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true as a primary resource)..
However my question is different. I want to specify the extensions (asmx to be precize) to be compressed. That's perfectly doable at the webserver level but somehow I am not able to understand, how can i set it up at the site level . This is required because, in a deployment scneario, there could be multiple web apps hosted under same IIS and client is not interested in turning on compression on asmx other than my app.
Can someone help?
While researching further, I came across this resource which has explained about enabling the compression at site level.
In a nut shell here are the steps
Open Internet Information Services (IIS) Manager:
In the Connections pane, go to the connection, site, application, or directory for which you want to enable compression.
In the Home pane, double-click Compression.
In the Compression pane, check the boxes to enable static or dynamic compression, or remove the check marks to disable static or dynamic compression.
Once you have completed the above steps, click Apply in the Actions pane.