- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Apr 2015 13:30:39 +1000
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Odin Hørthe Omdal <odinho@opera.com>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>, Karl Dubost <karl@la-grange.net>, "Julian F. Reschke" <julian.reschke@gmx.de>, Adam Barth <w3c@adambarth.com>, WebAppSec WG <public-webappsec@w3.org>
> On 3 Apr 2015, at 8:25 pm, Anne van Kesteren <annevk@annevk.nl> wrote: > > On Thu, Apr 2, 2015 at 11:02 PM, Odin Hørthe Omdal <odinho@opera.com> wrote: >> From how I read Fetch >> now, it seems as if the 304 would simply get in the cached response from >> last time, and thus also the CORS responses that were part of that >> original 200. > > No. Per the current specification CORS is checked first, then the > response code is handled. So a 304 without corresponding CORS headers > would result in a network error before the status is even looked at. From <https://fetch.spec.whatwg.org/#http-fetch>: """ 4.2 HTTP fetch […] 5. Set response to the result of performing an HTTP network or cache fetch using request with credentials flag if set and authentication fetch flag if set. 6. If the CORS flag is set and a CORS check for request and response returns failure, return a network error. """ 304 is applied to the response in "HTTP network or cache fetch," but you don't allow for the handling of conditional requests there (which all browsers do implement). I'd be happy to work on some proposals to fix that, if you're amenable. > We can change that, but we'd need to be careful not to introduce new > cross-origin attack vectors. Proposals welcome. Not sure what's new here — every browser I tested passed the core of that suite. Trying to apply CORS to a 304 pre-cache will not only go against current practice, it'll also cause incompatibility with deployed servers and proxies (as discussed ad nauseum last time around). Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 8 April 2015 03:31:09 UTC