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

On Mon, Apr 28, 2014 at 9:43 AM, Nils Goroll <slink@schokola.de> wrote:

> 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
>

I see this question come up a lot, either for multi-origin support in the
ACAO header, regex support in either the ACAO and/or ACAH headers, or
confusion over why the * value doesn't work in the ACAH header. If it won't
be supported, it'd be useful for the spec to explicitly state why not, to
avoid this confusion in the future.

However, I think this would be a useful feature, and would help make the
preflight cache more relevant. Server authors are already writing this type
of logic, they just put it in their server code. And then they curse at why
adding CORS support can't be as easy as updating a web.config or .htaccess
file. All existing CORS implementations would continue working, the worse
that would happen is that older user-agents would reject newer requests
(e.g. an older user-agent would do a string comparison between http://*.
example.com and http://www.example.com and reject the request). As a server
author, you'd have to decide whether supporting the "new CORS" format is
worth it, which is the same decision server authors had to make when
supporting CORS in the first place.

Thanks,
Monsur


>
> 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
>
>
>