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

Re: #337: Field names in cache-control header arguments

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 3 Mar 2012 11:22:41 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <BBA3C629-03A1-4289-8C1A-B3ABA5A4E465@mnot.net>
To: Henrik Nordström <henrik@henriknordstrom.net>
So, it seems like we have three options:

1. leave it alone.

2. align the language in no-cache with that in private.

3. deprecate the semantics of these values (but still allow them syntactically).

Personally, I'm in favour of #3; I love using esoteric features of caching, but this one has never been useful IMO.

What's your preference?

On 21/02/2012, at 8:10 PM, Henrik Nordström wrote:

> tis 2012-02-21 klockan 15:27 +1100 skrev Mark Nottingham:
>> Notice that private is about whether the specific field-names can be
>> stored, where no-cache is about validation. 
> There is no way in HTTP to revalidate headers other than to not cache
> them and only use any new values seen from a revalidation response.
>> These are two very different behaviours, which is why I think this is
>> underspecified and an interop problem.
> It's two slightly different wordings with the same result and meaning.
> These headers MUST NOT be given from cache when servicing future
> requests from a cached copy of this response, or any older responses
> it's merged with.
> It's possible that the description of private really mean to say MUST
> NOT store, not MUST NOT cache, making them differ on where the headers
> must be filtered (storing in cache vs reading from cache), but end
> result in responses to future requests is the same regardless.
>>>>     Note: Most HTTP/1.0 caches will not recognize or obey this
>>>>     directive.  Also, no-cache response directives with field-names
>>>>     are often handled by implementations as if an unqualified no-cache
>>>>     directive was received; i.e., the special handling for the
>>>>     qualified form is not widely implemented.
>>> I don't see a need for bloating the specification with this note. It do
>>> not add any value, only confusion.
>> That note has been in there for quite some time, and was added based upon previous discussion.
> I remember the discussion, but it's kind of pointless and
> counter-productive to have this note in the specification in the longer
> perspective.
> This holds for pretty much any other MAY there is in the specification,
> these are not widely implemented. There is reasons why these are MAY and
> not SHOULD.
> Regards
> Henrik

Mark Nottingham   http://www.mnot.net/
Received on Saturday, 3 March 2012 00:23:09 UTC

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