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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: hdanniel, Assigned: gerv)
Details
(Keywords: verified1.9.0.4, Whiteboard: [fixed in 454816])
Attachments
(1 file)
607 bytes,
patch
|
pamg.bugs
:
review+
samuel.sidler+old
:
approval1.9.0.4+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•16 years ago
|
Version: unspecified → 3.0 Branch
Comment 1•16 years ago
|
||
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
Updated•16 years ago
|
Summary: eTLD list blocks second-level .pe domains, which are now exist → eTLD list blocks second-level .pe domains which now exist
Comment 2•16 years ago
|
||
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
Comment 3•16 years ago
|
||
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).
Assignee | ||
Comment 4•16 years ago
|
||
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
Reporter | ||
Comment 5•16 years ago
|
||
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!
Assignee | ||
Comment 6•16 years ago
|
||
Obvious patch. Gerv
Assignee: nobody → gerv
Attachment #336497 -
Flags: review?(pamg.bugs)
Comment 7•16 years ago
|
||
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+
Assignee | ||
Comment 8•16 years ago
|
||
changeset: 18744:a1d3449a2cba Fixed. Gerv
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Flags: blocking1.9.0.4? → blocking1.9.0.4+
Updated•16 years ago
|
Attachment #336497 -
Flags: approval1.9.0.4+
Comment 9•16 years ago
|
||
Comment on attachment 336497 [details] [diff] [review] Patch v.1 Approved for 1.9.0.4. a=ss for release-drivers.
Assignee | ||
Comment 10•16 years ago
|
||
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
Updated•16 years ago
|
Keywords: fixed1.9.0.4
Whiteboard: [fixed in 454816]
Comment 11•16 years ago
|
||
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/?
Reporter | ||
Comment 12•16 years ago
|
||
Al, yes the cookie is sent properly in the nightly build. Actually, from Firefox 3.0.2 everything is working fine about this issue.
Comment 13•16 years ago
|
||
thanks. I'll mark this as verified then.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.4 → verified1.9.0.4
You need to log in
before you can comment on or make changes to this bug.
Description
•