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

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/

Received on Thursday, 21 June 2012 03:36:16 UTC