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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 21 Jun 2012 13:35:26 +1000
Cc: Julian Reschke <julian.reschke@gmx.de>, <ietf-http-wg@w3.org>
Message-Id: <21245210-A03A-4BC1-AC26-2C3123678339@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>
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? 


Mark Nottingham   http://www.mnot.net/
Received on Thursday, 21 June 2012 03:36:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC