- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 9 Dec 2013 15:20:27 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Karl Dubost <karl@la-grange.net>, Mark Nottingham <mnot@mnot.net>, Odin Hørthe Omdal <odinho@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Adam Barth <w3c@adambarth.com>, WebAppSec WG <public-webappsec@w3.org>
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. > However, in most cases when 304 responses are involved the website doesn't > actually see the 304 response. Most of the time the website makes a request > for a resource. If the UA has that resource cached, it will then make a > if-modified-since request. If a 304 is returned, without cors headers, then > the UA will return the originally cached response. If this cached response > does have the appropriate cors headers then permission should be granted. Okay, I was led to believe Firefox requires CORS headers in this scenario. -- http://annevankesteren.nl/
Received on Monday, 9 December 2013 15:20:58 UTC