W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: CORS and 304

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Fri, 03 Apr 2015 12:11:50 +0200
Message-Id: <1428055910.1217324.248895029.698E9C8A@webmail.messagingengine.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC