- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 05 Sep 2008 09:53:27 +0200
- To: "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Sunava Dutta" <sunavad@windows.microsoft.com>, "Maciej Stachowiak" <mjs@apple.com>, "Sharath Udupa" <Sharath.Udupa@microsoft.com>, "Zhenbin Xu" <Zhenbin.Xu@microsoft.com>, "Gideon Cohn" <gidco@windows.microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "IE8 Core AJAX SWAT Team" <ieajax@microsoft.com>
On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking <jonas@sicking.cc> wrote: > The only thing that i _know_ of is that: > > http://foo.com > and > http://foo.com:80 > > are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) > I have also heard that some UAs are able to handle non-ascii characters > in header values by somehow specifying an encoding. I don't really know > how that works, but for those UAs the following to origins would be > equivalent: > > http://www.xn--jrnspikar-v2a.com > and > http://www.järnspikar.com Using the latter is non-conforming for Origin and also non-conforming for Access-Control-Allow-Origin, which per its current definition either mathces Origin literally or is a wildcard. So currently RFC 2047 extensions are simply not supported (and not needeD) by the specification. Given that interoperability on encoded-word is very poor I suggest we keep it that way. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Friday, 5 September 2008 07:54:08 UTC