Closed
Bug 539849
Opened 15 years ago
Closed 1 year ago
Consider un-punycoding some or all IDNs in cookies/cookies exceptions lists for display and/or search
Categories
(Camino Graveyard :: Preferences, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: alqahira, Unassigned)
References
()
Details
Attachments
(1 file)
|
104.23 KB,
image/png
|
Details |
As part of the investigation of bug 534809, I discovered that all IDNs show up in cookies/cookies exceptions lists in punycode form.
This means that if you want to delete cookies (or change an exception, for instance the site needs a cookie to work/stop redirecting/allow comments/etc. and you'd initially chosen Deny), you have to guess at what to search for in order to deal with these cookies.
*I* knew that punycoded domains all start in xn-, so I could at least find all the punycoded domains, but I can't tell http://例子.测试/首页 from http://简体中文.idn.icann.org/首页 from http://مثال.إختبار/الصفحة_الرئيسية from http://중고차.com/ (which, since it's in .com, Gecko always punycodes for hostname purposes) when I want to deal with those cookies.
I can think of a few ways of dealing with this:
1) Always display domains in IDN format in cookies/exceptions
1a) Always display domains in IDN format, but allow searching based on either IDN or punycode
2) Display domains in IDN format depending on Gecko's IDN policy (so what people see in the cookie request sheet and the location bar matches what they search for)
2a) As 2, but allow searching based on either IDN of punycode
3) Always display domains in punycode format, but insert IDN variants into the search array to allow for searching based on IDN or punycode
Gecko suffers from this same bug (as bug 196305) and has no recommendations, but initial indications seem to lean toward 1.
Safari appears to do 1, except that it stores cookies for http://중고차.com/ and http://xn--299ap84c39b.com/ (the IDN and punycoded versions of the same domain) separately, depending on how the site was accessed, so it's really doing some distorted variant of 2.
Chrome doesn't appear to support IDNs (and its cookies can't be viewed, anyway).
OmniWeb doesn't appear to support IDNs.
Opera doesn't appear to support IDNs.
iCab has this same bug as Gecko.
The newest version of Shiira, 2.3 (good luck finding it, though), supports IDNs, but I can't get its prefPanes to open, so I have no idea what it does.
I think I'd prefer 1a or 2a; 1a has better consistency overall, but 2a is more consistent per site and may help users slightly more.
Comment 1•15 years ago
|
||
In a 24hours old Chromium build: everything is punycode.
for http://중고차.com/
| Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #0)
> Opera doesn't appear to support IDNs.
Er, sorry, I downloaded Opera 10.1 but somehow tested the older version; 10.1 supports IDNs, but the cookies are still only punycode.
| Reporter | ||
Comment 3•15 years ago
|
||
We should do the same thing in the pop-ups exceptions list; probably should be a new bug, but we can file it later (particularly as pop-ups and Flashblock have the poor exceptions list.)
If someone can find an example site with a log-in form, we should check the Keychain exclusions list, too.
| Reporter | ||
Comment 4•15 years ago
|
||
(In reply to comment #3)
> If someone can find an example site with a log-in form, we should check the
> Keychain exclusions list, too.
We can actually run this test via the Mochitest harness: http://wiki.caminobrowser.org/Development:Testing_arbitrary_scenarios_with_Mochitest
You need to log in
before you can comment on or make changes to this bug.
Description
•