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

On 3/03/2012 1:22 p.m., Mark Nottingham wrote:
> 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?

I'm in favor of #2.

Despite its absence from implementations (so far) it is a useful feature 
which allows bandwidth optimisation in edge cases where stale-if-error 
breaks. For example; some optional client-specific headers with generic 
entity.

The big confusion around no-cache is that is *is* cacheable. I think 
that needs clarifying right at the top of its description.

Proposal:
"

   no-cache

       The no-cache response directive indicates that the response message
       is may become stale at any time and MUST NOT be used to satisfy a
       subsequent request without successful validation on the origin
       server.  A cache MAY store the response.

       If the no-cache response directive specifies one or more field-
       names, this requirement is limited to the field-values associated
       with the listed response header fields.  That is, a cache MUST NOT
       send the specified field-name(s) in the response to a subsequent
       request without successful validation on the origin server,
       whereas it MAY send the remainder of the response message.

       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.

"

Changes:
  * aligns paragraph phrasing from private with suitable word repacement for no-cache.
  * adds two MAY's about cache practice to clarify interoperability expectations by servers.
  * drops the explicit mention of use-cases ("This allows ...") since the other directives do not mention specifics


AYJ

Received on Saturday, 3 March 2012 01:58:51 UTC