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

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

From: Nils Goroll <slink@schokola.de>
Date: Wed, 30 Apr 2014 17:58:43 +0200
Message-ID: <53611DB3.5080104@schokola.de>
To: Anne van Kesteren <annevk@annevk.nl>
CC: WebAppSec WG <public-webappsec@w3.org>

Thanks for the pointer to the current draft

On 30/04/14 16:58, Anne van Kesteren wrote:
> 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.

I don't see that it has been foreseen to make seamless syntactical or semantical
updates to the CORS headers.

Here's a rough idea of how we could get ahead:

- Clients supporting "CORS2" add a request-header like

  CORS-Version: 2

- Servers not supporting CORS2 will simply respond as before:

  Either they send constant Access-Control-Allow-Origin and no
  Vary: Origin

  or they send Vary: Origin otherwise

- Servers supporting CORS2 send

  Vary: CORS-Version


  If the client supports CORS-Version: 2 they will send
  Access-Control-Allow-Origin with the new format and
  _no_ Vary on Origin.

  If they don't see the CORS-Version: Request header, they
  respond as described above and may need to add "Origin" to Vary,
  so Vary may end up as "Vary: CORS-Version, Origin"

If CORS1 response headers are is a subset of CORS2 response headers, we don't
need a CORS-Version _response_ header, but we might want to add it for clarity.


* Client CORS1	Server	CORS1

  No change to the current situation, Vary: Origin required
  for anything but constant Access-Control-Allow-Origin

* Client CORS1	Server	CORS2

  The client will only see an additional Vary: Value, no
  change otherwise.

  Sane Intermediates will respect Vary and never send
  a CORS1 response to a CORS2 client or vice versa.

* Client CORS2	Server	CORS1

  The server will ignore the CORS-Version request header
  behave as for case CORS1/CORS1

  The client might behave differently based on the presense of a CORS-Version
  _response_ header (or just exploit the fact that CORS1 is a subset of

* Client CORS2	Server	CORS2

  The client will check the response headers with new semantics

  Sane Intermediates will respect Vary and never send
  a CORS1 response to a CORS2 client or vice versa.

As long as CORS1 is still in use, we will see _one_ additional copy on
intermediates / caches / CDNs. Once all clients use the same CORS-Version:
request header, we will have reduced the number of copies.

Also, this could serve as a template for how to handle future extensions -
unless I have overlooked something of importance.

Received on Wednesday, 30 April 2014 15:59:09 UTC

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