4 ms·

I'm not sure that, as this article states "Chrome automatically tries to determine if the user typed in a domain and tries to resolve it in the background." W

by aj700 16y ago

I'm not sure that, as this article states "Chrome automatically tries to determine if the user typed in a domain and tries to resolve it in the background." When I first switched my windows ipv4 dns settings to use opennic i noticed: chrome knows that a string typed into the address bar (one that isn't already eventually found in history or typed before) that ends with any normal suffix .com .uk etc. is a url, instead of just a query to be sent to the default search engine. but it doesn't know what to do with strings that have opennic only suffixes like .free on them. unless i make it clear that i am typing a url and not a query, by putting http:// http:// on the front, it doesn't know that it is a url, because it has the non-standard .free or something on the end. typing example.free or www.example.free for the first time just sends it to the search engine. so it seems chrome only knows/validates the official dns suffixes.

soult 16y ago
I am only guessing here, but maybe Chrome uses the Public Suffix list behind this feature, which includes only "official" registries. http://publicsuffix.org/ http://publicsuffix.org/
hk9565 16y ago
Sounds like something we'd like to fix. Please file a bug at <http://new.crbug.com/> http://new.crbug.com/>. If you'd like to dig through the code and post a patch too, that will likely speed things up: <http://dev.chromium.org/developers/contributing-code> http://dev.chromium.org/developers/contributing-code>.
- aj700 16y ago
  i rechecked this with dns prefetching off and with it on. in either case, anything with a standard tld puts the url as the top/selected result on the pulldown, with "send as a query to search" as the second possibility. but if I have prefetching ON (which I didn't when I first encountered the issue) the prefetching finds non-standard domains (eg register.fur, register.ing) and their servers and homepage titles but the option to treat them as a url and just go to the page appears below the default option to treat them as a search in the pulldown, so just typing them in and pressing enter still sends them to search. whether that is a big deal is up to you. it seems silly that something.suffix is not treated as a url when the prefetcher has already found it.

by aj700 16y ago

soult 16y ago

I am only guessing here, but maybe Chrome uses the Public Suffix list behind this feature, which includes only "official" registries. http://publicsuffix.org/ http://publicsuffix.org/

hk9565 16y ago

Sounds like something we'd like to fix. Please file a bug at <http://new.crbug.com/> http://new.crbug.com/>. If you'd like to dig through the code and post a patch too, that will likely speed things up: <http://dev.chromium.org/developers/contributing-code> http://dev.chromium.org/developers/contributing-code>.

aj700 16y ago
i rechecked this with dns prefetching off and with it on. in either case, anything with a standard tld puts the url as the top/selected result on the pulldown, with "send as a query to search" as the second possibility. but if I have prefetching ON (which I didn't when I first encountered the issue) the prefetching finds non-standard domains (eg register.fur, register.ing) and their servers and homepage titles but the option to treat them as a url and just go to the page appears below the default option to treat them as a search in the pulldown, so just typing them in and pressing enter still sends them to search. whether that is a big deal is up to you. it seems silly that something.suffix is not treated as a url when the prefetcher has already found it.