W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [AC] Access-Control-Allow-Origin header syntax

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 29 Sep 2008 10:47:49 -0700
Message-ID: <63df84f0809291047t1fa6658lfe8427aa7dda3574@mail.gmail.com>
To: "Anne van Kesteren" <annevk@opera.com>
Cc: public-webapps <public-webapps@w3.org>

On Thu, Sep 25, 2008 at 12:35 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 25 Sep 2008 21:26:05 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> However I think that if we are using URI syntax for these headers we
>> should treat them as URIs and not as opaque strings. Everywhere else
>> in the product URIs are parsed and canonicalized before being
>> compared. We specifically do not use string comparisons. I think for
>> the sake of consistency with the rest of the web platform we should do
>> the same here, anything else is just unexpected behavior.
>
> The point is actually that the header does _not_ take a URI. It did at some
> point, but you didn't like that. It takes the ASCII form of an origin
> instead, identically to The Web Socket Protocol in HTML 5.

What says that an origin is not a URI? Sure, many URIs deny access,
but it looks to me like they are still subsets of URIs. If we say that
they are not URIs, why not go all out and invent a new syntax, such as

http.org.example.www:80

to allow the site http://www.example.org? This would reduce confusion
around them being URIs.

However I think it would be better to keep them as URIs, while saying
that if there is a path, or if the URI is not same-origin as the
Origin header then deny access.

/ Jonas
Received on Monday, 29 September 2008 17:48:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT