W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: CORS and 304

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 3 Dec 2013 20:56:21 -0800
Message-ID: <CAEeYn8iU9PgwMoXBOujEKNJose=xt341LWnO55aExww7hbcvaA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@annevk.nl>, Odin Omdal HÝrthe <odinho@opera.com>, Karl Dubost <karl@la-grange.net>, WebAppSec WG <public-webappsec@w3.org>, Adam Barth <w3c@adambarth.com>
The HTTPbis spec says that headers can/should be repeated if they are
relevant to caching.  Since the Access-Control-... headers influence client
caching behavior (although at a level slightly above HTTP, in a manner that
does impact whether cached data is valid for a given request) perhaps we
should recommend that they be resent even with 304?

On Tue, Dec 3, 2013 at 7:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> I don't see why 304s should be different than other redirects from a
> security point of view.
> So requiring headers seem like the right thing. Can't we just say that
> that's the case for all redirects?
> / Jonas
> On Nov 25, 2013 8:34 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>> Karl discovered a bug in the CORS protocol. We do not specify what
>> happens for a 304 response that does not have CORS headers. If we
>> follow the logic from redirects, we ought to require CORS headers in
>> that scenario.
>> Firefox does this. Chrome does not.
>> I want to nail this down in the 304 bit of
>> http://fetch.spec.whatwg.org/ at some point. I thought I'd raise it
>> here to see what people think.
>> --
>> http://annevankesteren.nl/
Received on Wednesday, 4 December 2013 04:56:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:35 UTC