https://bz.apache.org/bugzilla/show_bug.cgi?id=51223
--- Comment #18 from Mark Nottingham <[email protected]> --- > 304/307 are now required to have the cors checks That is not what it says. A 304 to a conditional request generated by a browser is not required to have CORS headers, because the cache will combine the 304's headers with the stored response. The Fetch spec has been updated to clarify that, and the tests at WPT as well. If you want to generate the conditional in your JS code -- rather than having the browser create the conditional -- then the processing of the 304 moves back to your code, while CORS checks still happen before your code runs. Therefore, they'll fail CORS checks unless the 304 contains CORS headers, and there appears to be browser interop on that. That's what Anne was talking about; it does not translate to a requirement that all 304s have CORS headers. HTTP doesn't require 304s to carry CORS headers because it's a generic protocol, and we can't update every server / intermediary every time someone adds a new header. Even if you can persuade Apache to implement this, other servers -- including intermediary caches -- won't necessarily do it, so you won't be able to rely upon the 304 always containing CORS headers. In a situation where you control the client *and* the server *and* the path between them, of course, you can ignore this. However, that's not the Web, and it's not even really HTTP. Could the folks who are encountering this problem speak a bit more about their use case -- specifically, why it's important to use a custom handler for 304, rather than letting the browser handle it? Have you considered using a different status code? -- 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]
