New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2009
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Can't resolve .local hosts (?)

Reported by evan@chromium.org, Aug 21 2009

Issue description

On  issue 11747  people report they can't load .local hostnames.

I wonder if it's just because we don't know .local is a domain suffix?  If 
you type in a .local, what happens?

CC'ing DNS masters.
 

Comment 1 by evan@chromium.org, Aug 21 2009

+the other other DNS master
(this isn't important, just want to be sure everyone's on the thread)

Comment 2 by agl@chromium.org, Aug 21 2009

If you try to goto a .local name, it will do a Google search (because it's not a 
recognised domain name), but it'll say "Do you want to goto http://xyz.local?" in an 
infobar.

Seems to be working as intended.

Comment 3 by evan@chromium.org, Aug 21 2009

I think we should add .local to the domain suffix whitelist.  Cases where you use a 
.local URL (at least on non-Windows machines, where zeroconf is built-in) dominate 
scenarios (I can't even think of one) where you're searching for a single word + 
.local.
Is the meaning of ".local" globally well-defined somewhere?

Would Mozilla make this change too?  We use an identical list.

If the answer to either of these is "no", I'm not really willing to make this change.

Note that people should be still able to visit real addresses with an explicit scheme 
or slash.  The bug you linked shows an error from the network stack that I don't 
think should be a result of not having .local in the eTLD set.  I think it may 
instead be some other bug.

Comment 5 by evan@chromium.org, Sep 1 2009

Comment 6 by evan@chromium.org, Sep 1 2009

Status: Assigned
The Mozilla folks have merged in .local and several other changes to their eTLD file.  
We should sync to the latest version, then this bug can be marked fixed.

Comment 8 by agl@chromium.org, Sep 23 2009

Status: Fixed

Comment 9 by bugdro...@gmail.com, Sep 24 2009

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=26976 

------------------------------------------------------------------------
r26976 | agl@chromium.org | 2009-09-23 13:41:55 -0700 (Wed, 23 Sep 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/effective_tld_names.cc?r1=26976&r2=26975
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/effective_tld_names.dat?r1=26976&r2=26975

Effective TLD: sync with upstream

This patch sync's us with Mozilla's upstream version of the eTLD list.

BUG= 19957 
TEST=Enter test.local into the omnibar. The default action should be to load http://test.local, just like test.com

------------------------------------------------------------------------

Project Member

Comment 10 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Sign in to add a comment