For web development on localhost I'm using domains with .loc extension at the end of a domain name.
For example: if I work on a site roses.com, the local development domain would be roses.loc
(defined in hosts file and IIS as a host-header in binding)
My preferred browser (the main browser I use for development is Chrome) but unfortunately
it does not recognize a domain name with .loc extension as http://rose.loc - it throws me onto a google search page each time I would type in rose.loc (without http://) in the beginning..
Have you experienced this in a similar way ? Is there some solution to that ?
Because during intensive development testing with clearing browser cache and restarting the browser for various reasons, it's getting pretty annoying to be thrown at a google search page instead of the development page where I expect to notice some changes, each time I forget to type in http:// before the url (and Chrome is the one who hides it by default, anyway..)
Google Chrome is pretty "smart" with this. It uses a list of known-good TLDs and assumes everything else is just a search term that happens to end in a dot followed with some characters.
99% of the time that's perfectly fine. It's "only" us developers and a few people with strange network setups that have to suffer for the good of the majority ;-)
You can try using .local as your TLD, as that's a defined domain for referencing local domain names (at least it's used in some mDNS systems).
The issue has been entered as #30636 in the Chromium bug tracker. One workaround that often (but not always) seems to work is to append / to your hostname. So try roses.loc/.
I've created a search engine with a keyword of 'l' (my local TLD is .l). The URL for the search engine is http://%s.l. Then, I simply type "l mysite" in the address bar and it takes me to mysite.l.
Here is a workaround I came up with for this bug: http://code.google.com/p/chromium/issues/detail?id=30636#c38
I have Chromium installed on Linux Mint, and have a few localhost websites here. (I use Firefox for all of my work, so I have just discovered something here with Chromium.) My local sites are called morse and a.z. I had to enter http://morse/ and a.z/ respectively to get these sites to load the first time. They produced quick links on the new tab's otherwise blank page.
After closing Chromium, I reopened it and I could enter just morse/ and a.z to visit these sites. Since I've never seriously used this browser, I have not tailored any settings in it. (I did not use the quick link icons, but instead typed in the address bar.)
My findings confirm the localhost example.TLD/ entry does work when entered for the first time.
About Chromium: I am using Version 106.0.5249.119 (Official Build) for Linux Mint (64-bit).
Related
I got a task to update a URL in a test (using Selenium, Java and Chromedriver) to a new URL. The page is the same, just at a new location. This test worked fine with the old URL.
I brought up an instance of Chrome and verified I could access the URL.
Then I changed the URL, committed to git, and ran on our Jenkins machine and it failed. The screenshot said "This site can’t be reached". I told a co-worker that I think the URL must be wrong (though it worked on my desktop without Selenium). He tried it and it loaded fine. I tried it again from a regular Chrome window and it loaded fine. I tried from Eclipse using Selenium and I got the message about the site could not be accessed.
So I ran Eclipse, stopped it right when Chrome came up but hadn't loaded a URL yet. I manually entered the URL (from copy/paste) and got "This site cannot be accessed). Then I brought up a regular Chrome window and pasted the URL in and it loaded fine.
I decided to look for differences. So in my regular Chrome window it was "Version 77.0.3865.120 (Official Build) (64-bit)". I did the same on the version running under Chromedriver and got "Version 77.0.3865.120 (Official Build) (64-bit)". So the same.
I did a search for the latest Chromedriver. It said for version 77 to please use 77.0.3865.40. This was not what I was using. So I downloaded the correct version and thought "surely this will fix it". I verified it was 77.0.3865.40 coming up. But, as you guessed it, I got the same problem after updating to the most compatible Chromedriver.
Some searches said that basically nothing would be able to tell, but there was one property that Chromedriver inserts. I don't know whether this would be enough to block a session using Chromedriver?
The only thing I can think of is that we have iBoss and possibly iBoss is blocking it? Either that or somehow the site is blocking it.
I would like to share the URL with you but I do not know whether that would be violating company policy. If I get permission, I will share the URLs.
by the way, the error is "ERR TUNNEL CONNECTION FAILED"
Got some internal help to help fix some settings
We use SATO CL412e printers to print labels (3x7), with the label coming from a local SSRS report. Until recently, this setup worked without issue. A few months ago we modified the label, and implemented (new implementation) at one site (Site A). Then a few weeks ago, we pushed the change out to another site (Site B) that had previously been using this label (old version). Since we did this, the label at Site B is... weird.
The barcode is quite clearly not right, and all the normal characters are squished together, and perhaps bolded. Theoretically, we have proved that it is not the application (which recently changed as well) or the label report because it works fine at Site A, as well as from a different printer (same model, same drivers, etc.) at Site B.
Yesterday the drivers at Site B were updated to match Site A, which resulted in no change. This morning we found a few settings in the web interface that were different. I have not heard yet, but I seriously doubt it will have an effect.
What am I missing? To date, this exactly configuration works on three printers, and fails on one. I am at a complete loss as to what to check next. What could possibly cause this behavior?
Edit:
It has been discovered that this happens only through RDP. When we use a Citrix connection to the same server, we have no problem. It has been suggested that maybe this is a problem with the Internet Explorer settings. Any basis to this, and what settings?
RDP has a feature which connects your local printers to the remote server. This can mean the printer you get when connected with RDP is different than the printer when you are locally working on that server, or using Citrix. It's possible your local workstation has the same printer defined with different settings.
In your RDP connection dialog, click "Settings" and click the "Local resources" tab. Then clear the "Printers" checkbox to prevent this behavior.
We're (me, a colleague and an outsourced dev) building an iOS webDav navigation App which we believe is having trouble validating a URL.
We're accessing a webdav server via the app. One of servers which is https://webdav.microdigit.org.uk/test/ works perfectly.
However our main server which is https://vpn.westbuckland.devon.sch.uk/webdav/ doesn't work.
It seems to be due to the extra dot in the URL but we're not sure.
This is our current expression:
NSString *myregex = #"\\bhttps?://[a-zA-Z0-9\\-.]+(?::(\\d+))?(?:(?:/[a-zA-Z0-9\\-._?,'+\\&%$=~*!():#\\\\]*)+)?";
It just seems odd that the app will connect to a standard length URL such as https://vpn.something.com/ or even starting from a subfolder such as https://vpn.something.com/webdav/
You can then go one more and add another "dot" to the URL such as https://vpn.something.org.uk/webdav
However when you go one further it will connect to https://vpn.something.edu.org.uk/webdav/ but when you start trying to load a file or navigate the file structure, it reports a 404 in the debugger as if the files are not found.
Is it the extra dot in the URL? It seems to be the only thing we can think of. Our outsource dev has been pretty good so far in debugging most of our code (which was a purchased fully licensed base) but we're now reaching the end of the road. If anyone believes it is the regex expression. What would someone recommend we use instead?
I am eager to know why localhost.com (without www) redirects to google.com. I also noticed that www.localhost.com gives a 404 page not found. I checked this in Firefox, Chrome and Internet Explorer all does the same. I checked the domain name records and it shows it belongs to Tucows and I am pretty sure Google doesn't own it and I know we can use http redirect to change it to a www or non-www version as the site owner wishes.
Interesting answer posted by Ken Watford, Google employee: http://www.quora.com/Why-does-http-localhost-com-redirect-to-Google
He claims someone bought the domain when the web was still young and kept it ever since, but he does not say who.
It looks like others have had the results as you, check out the links below.
Try here:
http://answers.yahoo.com/question/index?qid=20111105050333AATP1r5
or here:
http://forums.phpfreaks.com/topic/146474-localhost-redirects-to-googlecom/
I think localhost.com should be owned by google as I tried pinging it and it showed the ip of google.com.I still don't know why the DNS records shows tucows as the owner.
I have been searching this from long and finally i found complete solution after going through different answers.
As far as #pradeep's answer is concern, he is right that localhost.com is purchased and points to particular IP so it is redirecting.
But we can override domain names in Windows platform for our local development PC via hosts file residing in C:\Windows\System32\drivers\etc as per #Faysal's answer.
Open hosts file as administrator and enter following line
127.0.0.1 localhost.com
But doing such also did not solve my problem. So i found final solution which will work in chrome browser.
In chrome you have to clear all dns cache via opening following url
chrome://net-internals/#dns
And here clear all cache and finally you will be redirect localhost.com to your local server's home page.
If you are using the Windows platform, then go to your %windir%\System32\drivers\etc and copy the host file to %userprofile%\Desktop. Open it with any text editor and remove the # sign from the front of 127.0.0.1 localhost. Save it and paste it back. Check if the problem is solved.
localhost.com is a website. It does not point to your local IP, instead it most likely has an A record pointing to Google's IP. It practically is Google, and I can prove it.
When the site worked if you connected using HTTPS then it would give a certificate error, the reason being that the certificate is signed to google.com but localhost.com is connecting.
I think the site has now been removed though.... I hope that solves it. It can cause some confusion since localhost points to 127.0.0.1.
I've found a dilly of a pickle with a new web server. We have a new web server that is displaying dates differently than our old web servers.
We are running asp classic web pages on IIS 6.0 with windows server 2003.
We have logged in as an administrator and set the regional settings as appropriate and then applied the settings to current user and default user profile.
We then went into registry and update the appropriate formats under HKEY_USERS/.default/control panel/international.
Update the asp.net configuration for our websites to the correct code-page and locale.
Does anyone have other places that the application could be getting date formats from?
I know this isn't the 'proper' way to fix the issue. However, the application was written many years ago, getting something through planning/change control would be a pain, and is the only application running on the server. Thus it is okay to configure the server to cater to this single application. Besides it was driving me crazy that a new server that should be configured identically to an old server was not working.
It turns out that in addition to HKEY_USERS/*/Control Panel/international, there is a setting for non-unicode programs. It can be found under HKLM/system/currentcontrolset/control/nls/language/Default. Set that to the correct code page and it is golden.
On the other hand, if you prefer to not modify the registry directly, you can update all these values through the Regional settings from the control panel.
You can adjust the formats through the 'customize' button.
You can change the 'language for non-unicode programs' under advanced tab.
Just make sure that you check the 'apply to the default profile' at the bottom of the advanced tab.
I don't think the highest vote answer is right, though it's close.
I had to use regedit to change all the internationalization settings of HKU\S-1-5-19\Control Panel\International (NT Authority) and HKU\S-1-5-20\Control Panel\International (Network Service) to match the settings that were already in HKU\S-1-5-18\Control Panel\International (Local System).
This worked perfectly.
I modified all the settings I could see which were different, by hand.
I should think I only really needed to change the settings for S-1-5-20 (Network Service).
Go to Control Panel -> Regional And Language Options, set all options you need, then under 'Advanced' tab select settings for non-Unicode programs and check 'Apply all settings to the current account and to the default user profile.'. Press OK and restart server.
On Windows Server 2008 administrators have additional 'Administrative' tab. There press 'Copy to reserved accounts'.
Classic ASP Defaults to the Locale ID that was configured when the server was Setup. If you have access to the original server run the following code to get Locale ID it's operating under and verify that the new server is using the same.
<%=Session.LCID%>
If the Locale IDs are different and you cannot change it on the new server then you can add a line to the Session_OnStart sub in the global.asa for the application that assigns the correct Locale ID to Session.LCID.
Using an ASP page with the content:-
Response.Write GetLocale
Might be informative, it'll show you what locale VBScript thinks its using.
I've seen issues like this in the dim and distant past when using integrated security. The ASP caches the regional details from a user hive when it first needs to use them then continues to use those settings until the process dies. ASP gets these settings from the user hive associated with the user identity the code is currently running under. Most of the time that would be DEFAULT because the user doesn't have a profile on the system.
However if the user happens to have logged on interactively to the server they will have a profile and so their settings are used. Hence I've seen situations where the server appears to have intermitten problems with regional settings.
I can't recall if I've seen this on IIS6, I've definitely seen it on IIS5.
If you run your ASP application under a different account (not IUSR_Guest)
Login as that account, set date/time format to what you want and restart IIS.