User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030306 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030306 Can not read IDN site in "Cookie Sites" tab on CookieManager. Cookperm.txt is writen by UTF-8. Reproducible: Always Steps to Reproduce: 1. 2. 3.

darin: if I understood your explanation of IDN goodness the other day, this is wontfix, right? (there's actually no way to fix it either, since we just have some mangled-looking ascii value that happens to mean something to DNS?)

Sorry, Component is change. Cookies -> Internationalization

dwitte: no actually we can fix this. we just have to be very careful about how we handle hostnames. we can use nsIIDNService to convert between the ASCII compatible (garbage looking) encoding to UTF-8 and back again. cookie manager needs to be smart about displaying only the unicode version. but, i think there are bigger problems with cookies in general working with GetHost when it should be working with GetAsciiHost, etc.

added intl folks to the cc list

ok, pulling this into the 1.4 milestone.

great, so we have a magical nsIIDNService ;) so the fix consists of the following? a) switch to GetAsciiHost everywhere in cookie code b) use a ->unichar conversion, and a call to nsIIDNService, when we need to display the host note that (a) has been done in the phase 2 patch; permissions will also need to be updated (may already be done in mvl's latest patch). (btw, I presume nsIIDNService knows when it's getting an IDN ASCII value, by some special prefix in the string?)

your plan sounds right on... >(btw, I presume nsIIDNService knows when it's getting an IDN ASCII value, by >some special prefix in the string?) yes. there are special ASCII valued prefixes defined by the IDN spec, various drafts, and fun prototype implementations. or something like that ;-)

i18n triage team: nsbeta1-

*** Bug 245160 has been marked as a duplicate of this bug. ***

I cannot read Punycode. Please decode Punycode to IDN.

The hosts come from nsIPermission.idl. 54 readonly attribute AUTF8String host; Is a 'host' thoughout mozilla genally understood to be already decoded? In other words, should the patch touch permission code or cookieviewer code?

(In reply to comment #11) > The hosts come from nsIPermission.idl. > 54 readonly attribute AUTF8String host; > Is a 'host' thoughout mozilla genally understood to be already decoded? In other > words, should the patch touch permission code or cookieviewer code? Hostnames in Mozilla, especially when passed as an AUTF8String are expected to be IDN. However, it is possible for ACE versions of the Hostnames to be passed through this API. The cookie code deals almost entirely with ACE hostnames. But, for UI purposes it really should be dealing with IDN. I think we probably need to add some careful conversions between IDN and ACE in the cookie service. The cookie service should accept input as either IDN or ACE, treat them as equivalents, and then pass them out as IDN.

It's possible that we may need to / want to make similar changes to nsPermissionManager. Perhaps it should support input that is either IDN or ACE, but my hope is that we can deal almost entirely with IDN and only convert to ACE when working with low-level protocols (e.g., the domain attribute of a cookie).

hmm... can you point me to some resources explaining ACE and IDN? with regard to cookies... what do you think would be the neatest blue-skies solution? could we deal entirely with IDN, or do we require ACE (e.g. when comparing hostnames, as you implied)?

(In reply to comment #14) > hmm... can you point me to some resources explaining ACE and IDN? heh :-) familiarize yourself with nsIIDNService. it has methods to test whether or not a string is ACE encoded. it also has methods to convert between ACE and IDN. IDN implies a non-ASCII, UTF-8 encoded hostname string. you can test if a hostname is IDN, by testing whether or not it contains non-ASCII characters. %-encoding is not allowed in hostnames, so you don't have to worry about that. nsIIDNService also has a method that allows you to normalize an IDN to the canonical form. the canonical form is also UTF-8 encoded. to compare to hostnames, you either need to compare the canonical form or the ACE encoded version. for cookie strings, you are working with ASCII only domain names, so you need to work with ACE.

"新宿駅.jp" is recorded as "xn--oct34u4y7b.jp" in cookies.sqlite .