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

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

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Tue, 21 Feb 2012 10:10:36 +0100
Message-ID: <1329815436.31567.24.camel@home.hno.se>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

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

Received on Tuesday, 21 February 2012 09:11:12 UTC

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