Re: CORS and 304

On Tue, Dec 10, 2013, at 03:05, Mark Nottingham wrote:
> On 10 Dec 2013, at 2:20 am, Anne van Kesteren <annevk@annevk.nl> wrote:
> > On Wed, Dec 4, 2013 at 7:51 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> Otherwise it means that you can just read 304 responses from any website
> >> without any security checks at all. And I think making the claim that a 304
> >> response couldn't possibly contain sensitive data is too bold of a claim.
> > 
> > That seems fair. The logic of when to show 304 to the API and when 200
> > is currently not very well defined however... Need to figure that out
> > some day.
> 
> Right. 304s shouldn't show up post-cache, because the cache is
> responsible for combining the 304 with the stored response to make the
> current response. 
> 
> The problem comes in when you want to do your own cache and generate your
> own conditionals (e.g., If-None-Match); since CORS needs to happen before
> the response is exposed to the app (and therefore the in-app cache),
> you're kind of stuck.

What became of this thread?

I'm reviewing Mark Nottingham's 304 CORS test.  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.

But Mark's tests also allows the 304 to layer new directives on top of
the ones that already exists.

So, a new Access-Control-Allow-Headers: would override earlier (or
non-existing) ones.  In the actual test it exposes an A header, but this
is also included in the 304 reply.  Though the case of exposing some old
header that was in the 200, should probably also get a test.  Either
positive or negative.


Anyway, waddap with this?

-- 
  Odin Hørthe Omdal
  odinho@opera.com

Received on Thursday, 2 April 2015 21:02:53 UTC