W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: CORS and 304

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 8 Apr 2015 06:52:29 +0200
Message-ID: <CADnb78iBhQKzsCnAeHa_qeB48-8SKQofWxUYrxM17u2=hW7TrA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Odin Hørthe Omdal <odinho@opera.com>, WebAppSec WG <public-webappsec@w3.org>
On Wed, Apr 8, 2015 at 6:41 AM, Mark Nottingham <mnot@mnot.net> wrote:
> You only get a 304 (legitimately) when you send a conditional request, and the browser will only send a conditional request when it has something in cache — but that thing is stale (hence the conditional request).

Right. And in that case the requesting party sees a 200 (or whatever
was cached I supposed), not a 304. Looking forward to your suggestions
on fixing this.


> If the client-side code is generating the conditional request and trying to handle the 304 themselves, yes it's a problem (and IIRC we left that as unsolveable last time around).

In that case we should probably require same-origin-or-CORS (the
current code path). Otherwise we might end up exposing bits in the 304
response that were not meant to be seen. But I guess we should also
see what browsers do here if that's not yet covered.


> IIRC it was the stuff you asked me to add around Access-Control-Expose-Headers.

Ah okay, so browsers fail at combining headers?


-- 
https://annevankesteren.nl/
Received on Wednesday, 8 April 2015 04:52:52 UTC

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