- From: Hill, Brad <bhill@paypal.com>
- Date: Wed, 4 Dec 2013 23:24:23 +0000
- To: Mark Nottingham <mnot@mnot.net>
- CC: Karl Dubost <karl@la-grange.net>, Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, Julian Reschke <julian.reschke@gmx.de>, Odin Hørthe Omdal <odinho@opera.com>, WebAppSec WG <public-webappsec@w3.org>, Adam Barth <w3c@adambarth.com>
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/ > > > >
Received on Thursday, 5 December 2013 21:53:20 UTC