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 16:54:18 +0200
Message-ID: <53610E9A.3020303@schokola.de>
To: Anne van Kesteren <annevk@annevk.nl>
CC: WebAppSec WG <public-webappsec@w3.org>

On 30/04/14 16:04, Anne van Kesteren wrote:
> On Wed, Apr 30, 2014 at 2:56 PM, Nils Goroll <slink@schokola.de> wrote:
>> On 30/04/14 14:47, Anne van Kesteren wrote:
>>> It is. You could terminate the request if the Origin request header
>>> was not "correct".
>> How should this work with CDNs and downstream caches?
> Whether downstream caches have a copy seems like enough of a headache
> for developers to not link your font inappropriately. It might
> sometimes work, and sometimes not.

I'd say this completely misses the point. The point I have brought up is a
general one, not one about developers' brains.

Once you deliver an object with "Access-Control-Allow-Origin: *" and
Cache-Control headers which allow for downstream caching, subsequent requests to
 intermediates will be fulfilled by those and the object will be delivered with
"Access-Control-Allow-Origin: *" no matter what the Origin request header was.

The logic you are proposing simply cannot be implemented on downstream caches,
and will be hard to implement on many CDNs.

>>> If we were to do this at this point we probably have to introduce a
>>> new header or force everyone to sniff user agents for support.
>>> However, there haven't been many requests for it.
>> I don't understand how sniffing user-agents relates to this issue.
> If we introduce new syntax it would break older clients (they would
> not get anything).

If you were to propose user-agent sniffing on the server-side, this implied to
add "Vary: User-Agent" to the response - which would, due to the high variation
of User-Agent strings, kill any caching. So this is absolutely no option to
address the issue I have brought up - which is about a less significant caching

What about this:


	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.

Received on Wednesday, 30 April 2014 14:54:43 UTC

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