Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Remove .local from PSL

RESOLVED FIXED in Firefox 11

Status

()

Core
Networking: Domain Lists
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: gerv, Assigned: Jothan Frakes)

Tracking

unspecified
mozilla13
Points:
---

Firefox Tracking Flags

(firefox11 fixed, firefox12 fixed)

Details

(Whiteboard: [qa-])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Currently, .local is in the PSL. The front page of publicsuffix.org says "A "public suffix" is one under which Internet users can directly register names." (Implicitly, in the IANA DNS root.)

So, we should remove .local. Then, the PSL will again be useful for checking whether a domain name is publicly registrable or not.

Gerv
(Assignee)

Comment 1

6 years ago
In a clinical sense, for purity of the premise of "Public", I agree.  I did a little more research on .local and found a few spots to see if I could backfill my institutional knowledge on why this was listed in the first place.

I am new as a volunteer here, but I wonder if consideration for RFC 2965 http://www.ietf.org/rfc/rfc2965.txt counts in the approval process for this change as treating 'public' with respect to how local behaves as a special case to respect interoperability with Linux and Apache.

Apache has a failover in their code for .local
http://hc.apache.org/httpcomponents-client-ga/httpclient/clover/org/apache/http/impl/cookie/RFC2965DomainAttributeHandler.html

.local is often a Linux installer's "Hello World" of TLDs, and many LAMP installations (quite popular) depend upon this.

Just putting this in here to document these.  I don't disagree with pulling .local, but it might have crept in with some good logic.
(Assignee)

Comment 2

6 years ago
Revised Apache.org Link:
http://hc.apache.org/httpcomponents-client-ga/httpclient/clover/org/apache/http/impl/cookie/RFC2965DomainAttributeHandler.html?line=131#src-131
(Reporter)

Comment 3

6 years ago
In the normal use of the PSL, having .local listed is a no-op, because the fallback behaviour is to treat any unknown domain as if it's listed just as itself. If people are using the PSL for other things than e.g. cookie setting, it might make a difference to them - but there's at least one use, which was the source of this bug report, where having .local messes things up.

Gerv
(Assignee)

Comment 4

6 years ago
Created attachment 536070 [details] [diff] [review]
Patch to remove .local
Assignee: nobody → jothan
Status: NEW → ASSIGNED
(Reporter)

Comment 5

6 years ago
Comment on attachment 536070 [details] [diff] [review]
Patch to remove .local

Jothan: when attaching patches, the right thing to do is "request review", by setting the "review" flag on the attachment to "?", with a requestee of whoever you want to do the review.

I'll review this one, but in future you could ask e.g. pkasting.

Gerv
Attachment #536070 - Flags: review+
(Assignee)

Comment 6

6 years ago
OK, cool.  

Will do on future items.   I am learning the process on these, so thanks for the patience while I am learning the force.
(Reporter)

Comment 7

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a56b449f8bc

Gerv

Comment 8

6 years ago
Should this be ->FIXED then?

Comment 9

6 years ago
https://hg.mozilla.org/mozilla-central/rev/8a56b449f8bc
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
(In reply to Peter Kasting from comment #8)
> Should this be ->FIXED then?

At least for now, I have to mark bugs manually after merging inbound to m-c, which is somewhat tedious so tends to get saved until a few hours after the merge.
(Reporter)

Comment 11

6 years ago
edmorley: you have come across Bugzilla's "mass change" feature, haven't you? :-)

Gerv
Unfortunately each bug needs it's own changeset pasted, a scan of the whiteboard to see if the bug needs to be kept open any longer & setting the assignee if it's been left blank - so sadly can't be set using mass change. My current brainstorming ideas for automating this are at https://etherpad.mozilla.org/automating-merge-bug-marking , but it's just a case of finding the time as a volunteer to do it :-)
(Reporter)

Comment 13

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/84c358b65105
https://hg.mozilla.org/releases/mozilla-beta/rev/006ca0def8bf

Gerv
status-firefox11: --- → fixed
status-firefox12: --- → fixed
Is there something QA can do to verify this fix?
Whiteboard: [qa?]
Whiteboard: [qa?] → [qa-]
You need to log in before you can comment on or make changes to this bug.