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

[Amos Jeffries <[e-mail]>]

On 13/02/2012 5:56 p.m., Mark Nottingham wrote:
> <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).

Its a hard sentance to phrase well. This new version still misses out 
mention of revalidation.

Perhapse a mention of whether it should erase the "private" control as 
well as the listed fields when storing and before re-use? That should 
make it a little clearer.

Perhapse something like:
"

That is, a shared cache MAY store and subsequently reuse the response, but MUST strip the specified field-names(s) and the private control before storing it.

"

NP: I include the private="..." control in the removal to help older 
caches see that the sanitized version of the response is cacheable. That 
is one useful detail which has been omitted entirely.


>
>
> 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.

I have seen some apps try to use them before they ran up against Squids 
lack of implementation. It did seem useful for them to specify some 
headers (ie Cookie or a custom equivalent) that if present needed 
revalidation, or if that failed the response was perfectly usable stale 
(or not even stale yet) without the header.

So,  IMO keep it as an option and we can implement, the Squid reasons 
for no implementation is simply we have not got that far through RFC 
2616 yet.

What I don't get is the nasty overlap between no-cache and 
must-revalidate. Why no-cache with field names is equivalent to 
must-revalidate for those fields, but must-revalidate has no field-names 
list at all.

It would seem common sense for clarity to deprecate no-cache entirely 
for senders and move the field list to must-revalidate. The result is 
self-explanatory, (but does sadly consume a few more bytes).

AYJ