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: Fri, 1 Jun 2012 13:33:02 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C7582278-E000-4D00-8C61-A91172EE582F@mnot.net>
To: "Ludin, Stephen" <sludin@akamai.com>
On 01/06/2012, at 10:05 AM, Ludin, Stephen wrote:

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

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.


> On 5/31/12 4:58 AM, "Mark Nottingham" <mnot@mnot.net> 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-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).
>> """
>> 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/
Received on Friday, 1 June 2012 03:33:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC