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

Re: CORS and 304

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 5 Dec 2013 10:27:37 +1100
Cc: Karl Dubost <karl@la-grange.net>, Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, "Julian F. Reschke" <julian.reschke@gmx.de>, Odin HÝrthe Omdal <odinho@opera.com>, WebAppSec WG <public-webappsec@w3.org>, Adam Barth <w3c@adambarth.com>
Message-Id: <7090423E-9E23-4736-8848-FF4B44E8C26A@mnot.net>
To: "Hill, Brad" <bhill@paypal.com>
If the freshness lifetime for a cached response is longer than the access-control-max-age, you're extremely likely to not see a request for it until the freshness lifetime has passed.

Even if you hack the browser cache to emit a request when the access-control-max-age has passed, an intermediary cache can and will return the old one.

I think I brought this up in my original reviews of CORS, but whatever...

Cheers,



On 5 Dec 2013, at 10:24 am, Hill, Brad <bhill@paypal.com> wrote:

> We still have the case where the headers indicating validity to the cache may give a longer lifetime than a supplied Access-Control-Max-Age.  In such cases, I would argue that regenerating the Access-Control headers is part of providing correct caching and validity information to the client, and therefore they SHOULD be included with a 304.
> 
> 
> On Dec 4, 2013, at 3:12 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> They aren't required; the cache that made the conditional request is responsible for correctly reconstructing the response, as per <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#freshening.responses>. 
>> 
>> Briefly, if a header isn't in the 304 response, you use the one from the 200 response.
>> 
>> You can't retroactively require servers to add new headers to 304 responses; they're (mostly) generated by server software that isn't aware of CORS (and shouldn't need to be).
>> 
>> Cheers,
>> 
>> 
>> On 5 Dec 2013, at 2:59 am, Karl Dubost <karl@la-grange.net> wrote:
>> 
>>> So clochix, who reported the issue, recreated a test case.
>>> http://cors2.clochix.net/
>>> 
>>> * First button creates a cross origin request and returns a 200.
>>> * Second button creates a cross origin request
>>> Response is 304, Apache removes CORS headers
>>> browser sends an error (Firefox 25+, Chromium 31)
>>> * 3 and 4 same requests for same domain (aka no CORS)
>>> 
>>> (hope it helps to understand)
>>> 
>>> -- 
>>> Karl Dubost
>>> http://www.la-grange.net/karl/
>>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 4 December 2013 23:28:09 UTC

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