W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2014

Re: CORS and Caching (in reverse proxies / CDNs)

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 30 Apr 2014 15:58:59 +0100
Message-ID: <CADnb78igTS4_8JJ1XnZBD0LzQJ6oKNT6rvvQU+aZ+prJWsQm7A@mail.gmail.com>
To: Nils Goroll <slink@schokola.de>
Cc: WebAppSec WG <public-webappsec@w3.org>
On Wed, Apr 30, 2014 at 3:54 PM, Nils Goroll <slink@schokola.de> wrote:
> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header

You want: http://fetch.spec.whatwg.org/#http-new-header-syntax

>         In practice the origin-list-or-null production is more constrained.
>         Rather than allowing a space-separated list of origins, it is either a
>         single origin or the string "null".
> Why has this note been added? If we could force implementors to follow the
> actual ABNF
>         Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":"
> origin-list-or-null | "*"
> this issue would vanish for many real world cases.

No, the space-separated syntax was about an older version of the
Origin header that would append an origin each time a cross-origin
redirect happened. Access-Control-Allow-Origin back then would still
have to match the Origin header of course. It was never about allowing
multiple origins. Anyway, you're reading a draft that's outdated.

Again, my point is that if we change Access-Control-Allow-Origin now,
user agents would barf at the new syntax and your fonts would stop
working completely. Preserving backwards compatibility or somehow
magically updating all deployed user agents is an important
consideration if we're going to make changes at all here.

Received on Wednesday, 30 April 2014 14:59:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:38 UTC