#337: Field names in cache-control header arguments

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/337>

> The discussion of optional field-names in "private" and "no-cache" is vague about whether the cache MAY or MUST revalidate when handling a subsequent request for that resource. That is, if another request for the resource comes in, and the cached response is still fresh, is the cache allowed to return it, minus the forbidden headers, or is it required to revalidate, and merge in new values of those headers from the 304 response?)

See <http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-18#section-3.2.2> for the relevant text.


I had a look at this. I think we can fix things for private -- proposal is to change:

... That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message.

to

... That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message (and subsequently reuse it).


However, the semantics of these arguments on no-cache is much less clear. IME this isn't implemented, so I'd suggest deprecating it by changing:

      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.  This
      allows an origin server to prevent the re-use of certain header
      fields in a response, while still allowing caching of the rest of
      the response.

      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.


To:

"""
The no-cache response directive was originally defined to allow specification of one or more field-names as a parameter value. However, this form is not widely implemented, and their semantics are not well-defined; as a result, this form is deprecated, and servers SHOULD NOT send them. Caches are advised to silently ignore these parameters and treat the response as if it had contained a bare no-cache directive.
"""

Comments? I'm not against also deprecating them in this fashion on private, if there's support for that.


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 13 February 2012 04:57:09 UTC