https://bz.apache.org/bugzilla/show_bug.cgi?id=51223
--- Comment #19 from [email protected] --- I've recently stumbled upon this issue. The problem doesn't occur when the CORS response headers are "static" (e.g. always a-c-a-o: *), but are dynamic. Basically, our setup serving static files is like this: SetEnvIf Origin "^http(s)?://(.*\.)?example.com(:[0-9]+)?$" has_origin=$0 Header always set Access-Control-Allow-Origin %{has_origin}e env=has_origin Header always set Vary Origin There are two problems for us now: A request can first be a non-CORS request (i.e. no Origin request header), but then in another context of our site with CORS (e.g. image in one place used ordinarily in an <img> element, but later fetched for use in a <canvas> with CORS). For the second request, Apache would answer with 304 *without* CORS headers, although IMHO it should. And the second problematic case is when the CORS response headers would change because of a changing Origin request header: First request from foo.example.com, response has A-C-A-O: sub1.example.com, then request to same resource from bar.example.com, Apache answers with 304 but again strips our CORS headers. So, even if CORS response headers are not *required* on 304 if they did not change from the cached response, they should still be allowed for answering with a 304. Or is there another way such a case should handled? Thanks -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
