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

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

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