- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Fri, 03 Apr 2015 12:11:50 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Mark Nottingham <mnot@mnot.net>, 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 Fri, Apr 3, 2015, at 11:25, Anne van Kesteren 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. > > We can change that, but we'd need to be careful not to introduce new > cross-origin attack vectors. Proposals welcome. OK, in other words it's anyway so that the the tests don't follow spec (though in another way than I thought from searching for 304 and only reading that #http-fetch part). Mark can probably articulate his proposal himself. I obviously don't want to take in tests that don't actually follow spec (doh). :) -- Odin Hørthe Omdal odinho@opera.com
Received on Friday, 3 April 2015 10:12:23 UTC