Closed Bug 450339 Opened 16 years ago Closed 16 years ago

eTLD list blocks second-level .pe domains which now exist

Categories

(Firefox :: General, defect)

3.0 Branch
x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: hdanniel, Assigned: gerv)

Details

(Keywords: verified1.9.0.4, Whiteboard: [fixed in 454816])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

I have a site with the domain example.pe . With firefox2 and opera the cookie is sent to the server (Apache 2 web server) but with firefox is not.
I test the same site (with the same configuration) moved to example.com.pe and it works fine. When I activate cookie logging in the server I have this in example.com.pe calling to play.php (var dump of $_COOKIE array) :

SESS3a18a87e35b377c6c0cf5b6f1151d000=d94f5s2pd4rlm4m1gi5isvb0j2; PHPSESSID=pv47dlprhjebgkajm2e5q33f21; SESSda8e28f0348737896c3a34376fef8171=1egr87ki7nrff19avm8is56681 GET /play.php HTTP/1.1 [12/Aug/2008:18:53:41 -0500]

But with example.pe:

- GET /play.php HTTP/1.1 [12/Aug/2008:18:53:58 -0500]

The cookie were sent empty or not sent at all. Also I tried with another domain example2.pe with the same results. But with firefox2 and opera it works fine.




Reproducible: Always

Steps to Reproduce:
1.
2.
3.



I check with other tools like firebug and firecookie and the result is the same, the cookie is not sent to the server from firefox3. I deactivate all the addons and clear the private data with the same results. We test first if was a problem with the application and everything is ok.
Version: unspecified → 3.0 Branch
We use a suffix list to determine invalid "public" domain levels that should never see cookies. See https://wiki.mozilla.org/Gecko:Effective_TLD_List (slightly out of date) and for the list itself see http://publicsuffix.org/

To get changes to the list we need a representative of the national registry to tell us their official policy. It sounds like the registry changed their policy from "no top-level domains" to allowing second-level domains less than a year ago.
http://en.wikipedia.org/wiki/.pe
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-firefox3.1?
Flags: blocking1.9.0.3?
OS: Linux → All
Summary: Cookie not sent through web sites with country top level domains → eTLD list blocks second-level .pe domains, which are now exist
Summary: eTLD list blocks second-level .pe domains, which are now exist → eTLD list blocks second-level .pe domains which now exist
Assuming wikipedia is accurate (ha -- thus the need for mail from the registry) I think the change would be something like

-*.pe
+pe
+edu.pe
+gob.pe
+nom.pe
+mil.pe
+sld.pe
+org.pe
+com.pe
+net.pe
At www.nic.pe you do indeed seem to be able to get foo.pe domains. I don't see *.sld.pe as a current option but they may have offered it in the past (www.sld.pe is owned by the registry).
The document with the new rules is here:
https://www.nic.pe/InformeFinalComision.pdf

It gives a long list of reserved names, but seems to suggest that only the above (without sld.pe) are open for registration at this time. There is no mention of sld.pe in the document. It was added in Jan 08 to the Wikipedia page by a UK-based user, Rrh02.

I suggest we go ahead without it for now. We are in the process of making a set of updates to the Public Suffix List from various sources. We'll add this one in too, and get the whole lot into the next point release of Firefox 3.

Gerv
I know that there are some *.sld.pe registered domains, and it seems they are working. I passed this information to nic.pe for they let us know which suffixes are valid besides the already added.

Thanks!
Attached patch Patch v.1Splinter Review
Obvious patch.

Gerv
Assignee: nobody → gerv
Attachment #336497 - Flags: review?(pamg.bugs)
Comment on attachment 336497 [details] [diff] [review]
Patch v.1

Good changes.  We can add sld.pe whenever we get back confirmation, if we do.
Attachment #336497 - Flags: review?(pamg.bugs) → review+
changeset:   18744:a1d3449a2cba

Fixed.

Gerv
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Flags: blocking1.9.0.4? → blocking1.9.0.4+
Attachment #336497 - Flags: approval1.9.0.4+
Comment on attachment 336497 [details] [diff] [review]
Patch v.1

Approved for 1.9.0.4. a=ss for release-drivers.
This got put on the 3.0 branch in file version 1.7, as part of bug 454816. See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/dns/src/effective_tld_names.dat&rev=1.7
 
Gerv
Keywords: fixed1.9.0.4
Whiteboard: [fixed in 454816]
 Héctor, can you verify that you are properly getting the cookie now if you use a nightly build from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla1.9.0/?
Al, yes the cookie is sent properly in the nightly build. Actually, from Firefox 3.0.2 everything is working fine about this issue.
thanks. I'll mark this as verified then.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: