W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: WGLC #353: Multiple Values in Cache-Control headers

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 3 Jul 2012 12:38:08 +1000
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, Amos Jeffries <squid3@treenet.co.nz>
Message-Id: <8F6879EE-0F3D-493A-9810-F1FBAC9ED6A8@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
I haven't heard any more discussion of this. As it is, we have a proposal to close this issue:

> Add a note to <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#calculating.freshness.lifetime>:
> 
> """
> When there is more than one value present for a given directive (e.g., two Expires headers, multiple Cache-Control: max-age directives), it is considered invalid. Caches SHOULD consider responses that have invalid freshness information to be stale.
> """

Feedback?

Regards,


On 21/06/2012, at 1:35 PM, Mark Nottingham wrote:

> On 12/06/2012, at 10:19 AM, Amos Jeffries wrote:
> 
>> On 12.06.2012 01:20, Julian Reschke wrote:
>>> On 2012-06-11 15:04, Amos Jeffries wrote:
>>>> ...
>>>> * flag parameters can't exactly contradict, so dropping/merging
>>>> duplicates and treating as one flag would seem okay. (only-if-cached
>>>> must-revalidate, proxy-ravalidate, no-cache, no-store, no-transform, etc)
>>> 
>>> "public" vs "private"?
>> 
>> Okay. Nasty case there.
>> "public" is specifically linked to the auth systems though isn't it?
>> 
>> Can we safely assume that "private" on auth responses is invalid and that "public" was intended to override it?
>> 
>> on non-auth responses "public" would seem to be the redundant state, and "private" assumed to be the desired behaviour?
> 
> Why are we trying to design a general solution to this problem?
> 
> The current spec already deals with these cases; follow the rules in <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#response.cacheability> and <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#constructing.responses.from.caches> and the precedence should be clear.
> 
> 
>>>> * time-delta parameters (max-age, s-maxage, etc) being conservative and
>>>> dropping the larger or equal of the two seems the right handling.
>>> 
>>> Yes, we could say that.
> 
> And indeed, there's already a proposal on the table here:
> 
>> Add a note to <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#calculating.freshness.lifetime>:
>> 
>> """
>> When there is more than one value present for a given directive (e.g., two Expires headers, multiple Cache-Control: max-age directives), it is considered invalid. Caches SHOULD consider responses that have invalid freshness information to be stale.
>> """
> 
> The SHOULD and <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#intro.conformance.and.error.handling> give implementations enough flexibility to recover if they wish, but I personally don't think we want to specify a particular behaviour here, because we'll very likely make current implementations non-conforming. Happy to talk through this one, though.
> 
> 
>>>> * list of tokens ... maybe combine? it is possible one proxy adds
>>>> no-cache="Foo" and another adds no-cache="Bar" and they both hit some
>>>> downstream cache which needs to handle both Foo and Bar properly.
>>>>  Yes the right thing to do woudl have been no-cache="Foo Bar". But
>>>> what if that is not done?
>>> 
>>> Right now we allow
>>> 
>>> no-cache="Foo, Bar"
>>> 
>>> Should
>>> 
>>> no-cache="Foo", no-cache="Bar"
>>> 
>>> be equivalent? (That would be similar with the use of list syntax in
>>> header fields)
>> 
>> I think so, yes.
> 
> 
> Given that this isn't widely used, I don't have a big problem with defining something here, but I do wonder if we're getting to diminishing returns.
> 
> Can someone please make a proposal? 
> 
> Thanks,
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 3 July 2012 02:38:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2012 02:38:42 GMT