- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 29 Sep 2008 10:47:49 -0700
- 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 UTC