- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Apr 2015 15:02:39 +1000
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Odin Hørthe Omdal <odinho@opera.com>, WebAppSec WG <public-webappsec@w3.org>
> 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