[RFC] Include `Origin` as `Vary` header for cacheable responses

[rvanlaak]

fixes #123

For cacheable responses the Vary header should include Origin to let caching proxies respect the request's origin.

[adri]

Great! It's btw not only caching proxies but also browsers which can cache the OPTIONS request.

[rvanlaak]

@Seldaek any comments on this PR? Would be great to get it merged.

[Seldaek]

2.1.0 is released

[lazka]

Shouldn't Access-Control-Request-Headers and Access-Control-Request-Method be added to Vary as well?

[fd6130]

Is the Vary working in this bundle? Cause cors error still occurs although the response contain Vary in a cached response.

a.example.com and b.example.com, the second one cors error because the response is from first one (both of them using same API).

[lazka]

Are you using Apache? Apache has a bug where it strips CORS headers from cached 304 responses. I'm currently fighting the same problem...

[fd6130]

S headers from cached 304 responses. I'm currently fighting the same problem...

You are right. I'm using Apache for my production, seems like we are facing the same issue. But mine are not 304 responses issue, but a http cache issue (i think?).

[lazka]

I'm currently planning to set 'forced_allow_origin_value' => '*' with this bundle, so that a (wrongly served?) cached responses still is valid for a different origin, haven't tested that though.

Does that make sense to you?

I'm having a hard time debugging the real cause, since both firefox and chrome hide so much of the cache logic, so I don't know where the wrong data is coming from.

edit: 'forced_allow_origin_value' => '*' made things work for me

[lazka]

The 304 issue in Apache is https://bz.apache.org/bugzilla/show_bug.cgi?id=51223

Something like https://lists.w3.org/Archives/Public/www-archive/2017Aug/0000.html indicates that browsers ignore the Vary header in some cases and still serve cached results... the forced_allow_origin_value should also work there... maybe.

I'm kinda baffled that all this is so broken..

[rvanlaak]

If I remember correct, after reading the related issue, setting it to * means the entire CORS policy will be undone.

The point of Vary is on which headers the cached response should be varied. So, this could be specific for each http server (e.g. Apache handles this differently as Symfony HttpCache or Varnish does).

[lazka]

Chrome here gives me a cached response with the wrong headers despite sending "Vary: Origin" though:

-> origin: foo.bar.com, if-none-match: foobar
<- access-control-allow-origin: not-foo.bar.com, etag: foobar, vary: origin
! CORS error: foo.bar.com != not-foo.bar.com