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

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Jun 2012 17:30:37 +1000

Revised proposal, based upon discussion:

> 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.
> """

Any further comments? Otherwise we'll close and incorporate.

Regards,

On 31/05/2012, at 9:58 PM, Mark Nottingham wrote:

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/353>
> 
> I think this issue is a re-hash of the discussions around error-handling. 
> 
> At most, we might add a note to <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#calculating.freshness.lifetime> like this:
> 
> """
> 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, but MAY attempt to recover (e.g., by using the most conservative value).
> """
> 
> The issue also suggests other places to look, but I'm inclined not to go too far down this path. 
> 
> Thoughts?
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jun 2012 11:57:25 +0200

On 2012-06-08 09:30, Mark Nottingham wrote:
> ...

Would it make sense to have generic text in the definition of 
Cache-Control about this?

Does the "must have a single value" rule apply to all directives? Can 
the definition of error recovery diverge per directive?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Jun 2012 20:06:39 +1000

On 08/06/2012, at 7:57 PM, Julian Reschke wrote:

> Would it make sense to have generic text in the definition of Cache-Control about this?

Don't think so, because...

> Does the "must have a single value" rule apply to all directives?

No; I've seen examples that use multiple values (can't remember what ATM)

> Can the definition of error recovery diverge per directive?

I imagine so.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jun 2012 12:15:09 +0200

> No; I've seen examples that use multiple values (can't remember what ATM)

If that is the case, we probably need to spend some more time on 
clarifying this, as this different from similar header fields.

>> Can the definition of error recovery diverge per directive?

Which makes it sound as if we should define it for all directives 
defined in this spec (as bad as this sounds)...

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 09 Jun 2012 00:10:43 +1200

On 8/06/2012 10:15 p.m., Julian Reschke wrote:
>>>>> 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.
>>>>> """
>>>>
>>>>

Or with a blanket to cover the generic "safe" erro rhandlign of dropping 
something. ie I would imagine duplicate identical controls it would be 
harmless to drop duplicates before interpreting the controls.

And a specific mention of anythign special for those directives with 
parameter values. Which face a more difficult time resolving multiples 
and non-duplicate values.

AYJ

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Jun 2012 21:57:57 +1000

On 08/06/2012, at 8:15 PM, Julian Reschke wrote:

> If that is the case, we probably need to spend some more time on clarifying this, as this different from similar header fields.

How so? I thought we'd agreed we don't have shared microsyntax / model for our existing headers...

> Which makes it sound as if we should define it for all directives defined in this spec (as bad as this sounds)...

If someone wants to point out specific instances where they believe it's important for security and/or interoperability, and it doesn't fall afoul of our stance on error handling, by all means.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jun 2012 14:10:51 +0200

> How so? I thought we'd agreed we don't have shared microsyntax / model for our existing headers...

At least for those headers that inherit MIME header field parameter 
syntax (such as C-T and C-D) I believe the consensus was that parameters 
can not get repeated. It might be hard to find something normative on 
that, though.

So let's rephrase this: optimally, we

- defined this for all header fields in the spec (optimally globally for 
all parameters of that header field), and

- advise people defining new header fields to do so as well (-> 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.3.1>)

> If someone wants to point out specific instances where they believe it's important for security and/or interoperability, and it doesn't fall afoul of our stance on error handling, by all means.

Right now we don't say anything what to do, for instance, with two 
max-age directives? If this is an invalid header field instance, we 
should say so. If it's not, we should say how to handle that.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 12 Jun 2012 01:04:24 +1200

On 12/06/2012 12:10 a.m., Julian Reschke wrote:
> syntax (such as C-T and C-D) I believe the consensus was that 
> parameters can not get repeated. It might be hard to find something 
> normative on that, though.
>
> - defined this for all header fields in the spec (optimally globally 
> for all parameters of that header field), and
>
>> If someone wants to point out specific instances where they believe 
>> it's important for security and/or interoperability, and it doesn't 
>> fall afoul of our stance on error handling, by all means.
>

* 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)

* time-delta parameters (max-age, s-maxage, etc) being conservative and 
dropping the larger or equal of the two seems the right handling.

* 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?

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jun 2012 15:20:13 +0200

> must-revalidate, proxy-ravalidate, no-cache, no-store, no-transform, etc)

"public" vs "private"?

> dropping the larger or equal of the two seems the right handling.

Yes, we could say that.

> 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)

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 12 Jun 2012 12:19:40 +1200

>> must-revalidate, proxy-ravalidate, no-cache, no-store, no-transform, 

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?

> be equivalent? (That would be similar with the use of list syntax in

I think so, yes.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Jun 2012 13:35:26 +1000

On 12/06/2012, at 10:19 AM, Amos Jeffries wrote:

> 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.

> 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 t…

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.

>> be equivalent? (That would be similar with the use of list syntax in

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,