W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: CORS and 304

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 4 Dec 2013 15:52:24 -0800
Message-ID: <CA+c2ei8m5Dqw0UrtJ0a=r-Q5GXSnszNgXAz8s6Ed93GvZWnahA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "Hill, Brad" <bhill@paypal.com>, Karl Dubost <karl@la-grange.net>, Anne van Kesteren <annevk@annevk.nl>, "Julian F. Reschke" <julian.reschke@gmx.de>, Odin HÝrthe Omdal <odinho@opera.com>, WebAppSec WG <public-webappsec@w3.org>, Adam Barth <w3c@adambarth.com>
I don't think it is. I think the Access-Control-Max-Age issue is
separate from the one that started this thread.

/ Jonas

On Wed, Dec 4, 2013 at 3:38 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Aha!
>
> Why is a 304 being returned for OPTIONS?
>
> Cheers,
>
>
> On 5 Dec 2013, at 10:36 am, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Wed, Dec 4, 2013 at 3:24 PM, Hill, Brad <bhill@paypal.com> wrote:
>>> We still have the case where the headers indicating validity to the cache may give a longer lifetime than a supplied Access-Control-Max-Age.  In such cases, I would argue that regenerating the Access-Control headers is part of providing correct caching and validity information to the client, and therefore they SHOULD be included with a 304.
>>
>> Access-Control-Max-Age only applies to OPTIONS responses which I
>> didn't think could ever be cached?
>>
>> / Jonas
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
Received on Wednesday, 4 December 2013 23:53:23 UTC

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