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

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 21:58:13 +1000

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

---

From: "Ludin, Stephen" <[email-masked]>
Date: Thu, 31 May 2012 19:05:51 -0500

I like the 'SHOULD' part, but I am uncomfortable with the MAY.  My crystal
ball sees multiple interpretations and implementation of recovery attempts
in the future.  I would suggest leaving the MAY phrase off as it seems to
only invite trouble.

-stephen

On 5/31/12 4:58 AM, "Mark Nottingham" <[email-masked]> wrote:

>At most, we might add a note to
><https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-ca
>che.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).
>"""
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jun 2012 13:33:02 +1000

The MAY is implied by <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#intro.conformance.and.error.handling>:

> Unless noted otherwise, Recipients may take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery could lead to dangerous consequences.

So, we can certainly leave it off (and I'm OK with that), but the text above will still apply.

Cheers,