- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 8 Apr 2015 06:52:29 +0200
- 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