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

CORS and Caching (in reverse proxies / CDNs)

From: Nils Goroll <slink@schokola.de>
Date: Mon, 28 Apr 2014 16:43:21 +0200
Message-ID: <535E6909.3050201@schokola.de>
To: public-webappsec@w3.org
Hi,

working on the Varnish / CDN configurations of some reasonably large web sites,
I wondered why, even for one of the simplest use cases, CORS is unnecessarily
cache-unfriendly.

Ref: http://www.w3.org/TR/cors/#resource-implementation

Please consider the simple case of a web font http://static.do.main/font.woff
which, for licensing reasons, is to be shared with a set of specific origins
only, so using 'Access-Control-Allow-Origin: *' is not an option.

As it stands, the spec demands to generate one cache object per origin, despite
the fact that the actual object (http body) is bit equivalent for all copies.

I wonder if the CORS model could be made more cache-friendly by reducing the
number of cases where "Vary: Origin" is required. From the perspective of the
use case discussed here, it would be sufficient to allow for

- simple patterns in Access-Control-Allow-Origin
- allowing for multiple Values in Access-Control-Allow-Origin

such as

	Access-Control-Allow-Origin: http://*.do.main, https://partner.site,
xmpp://future.extension

I have not yet made any attempt to address the question of cache friendliness on
a broader perspective of CORS.

I'd appreciate pointers if this issue had been discussed before, as I have
failed to find any previous discussion in the list archives.

Thank you, Nils
Received on Wednesday, 30 April 2014 09:38:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC