Closed Bug 660215 Opened 8 years ago Closed 8 years ago

Remove .local from PSL

Categories

(Core :: Networking: Domain Lists, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla13
Tracking Status
firefox11 --- fixed
firefox12 --- fixed

People

(Reporter: gerv, Assigned: jothan)

Details

(Whiteboard: [qa-])

Attachments

(1 file)

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
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.
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: nobody → jothan
Status: NEW → ASSIGNED
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+
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.
Should this be ->FIXED then?
https://hg.mozilla.org/mozilla-central/rev/8a56b449f8bc
Status: ASSIGNED → RESOLVED
Closed: 8 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.
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 :-)
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.