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

Re: CORS and 304

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 8 Apr 2015 15:02:39 +1000
Cc: Odin Hørthe Omdal <odinho@opera.com>, WebAppSec WG <public-webappsec@w3.org>
Message-Id: <709A5696-720E-42B5-9E13-5F87993B1E26@mnot.net>
To: Anne van Kesteren <annevk@annevk.nl>

> On 8 Apr 2015, at 2:52 pm, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
> 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.

I'll fork and do a pull. 


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

Seems reasonable.


>> IIRC it was the stuff you asked me to add around Access-Control-Expose-Headers.
> 
> Ah okay, so browsers fail at combining headers?

Yeah — but just as far as ACEH is concerned.

Cheers,


--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 8 April 2015 05:03:07 UTC

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