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

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