Re: CORS and 304

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.

XHR says:

> For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow author request headers to override automatic cache validation (e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [HTTP]

Cache validation driven by the author requires the CORS headers to be on the 304, but as discussed this isn't realistic for many origin servers (i.e., 304s are automatically generated), and if there's a caching proxy server that generates the 304, it's practically impossible. So the answer might be "Don't do that [cross-origin validating requests from an authored cache]."

Fetch says much the same thing, but AIUI ServiceWorker should be OK, because AIUI all of this machinery is hidden behind CrossOriginResponse in the Cache. Alex?


> 
>> 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/
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 10 December 2013 01:05:59 UTC