https://bz.apache.org/bugzilla/show_bug.cgi?id=51223
--- Comment #10 from Jörn Berkefeld <[email protected]> --- yes exactly - I am generating that manually. It's an API, not a static file. The problem is, that Apache strips the Access-Control-* headers that I also manually set from the response - even if I set that before the 304 header. It's also not about the browser which obviously is fine with being fooled into accepting the 304 even though it has nothing in it's cache to match that. works just fine on same-origin. Fails cross-origin due to the missing Access-... header. so once again: it's not about 304 being generated by Apache, but via whatever server-side script you use. Apache sends that 304 header but strips the CORS headers. That's essentially the same situation described by Michiel de Jong, only that I am using Apache+PHP on the server-side and not node.js, which, now that I think about it, actually was a bit of a weird example for an Apache bugtracker. Though uncle Google tells me he's probably doing it via mod_proxy. here is a blog-post coming to the same conclusion: http://blog.rampinteractive.co.uk/cors-html5-application-cache-manifest-dont-work-together-neither-cors-apache/ -- 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]
