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

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Feb 2012 15:56:42 +1100

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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 14 Feb 2012 02:27:08 +1300

On 13/02/2012 5:56 p.m., Mark Nottingham wrote:
> See<http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-18#section-3.2.2>  for the relevant text.
>
>

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.

> 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

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 16 Feb 2012 08:37:15 +0100

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

Ok.

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

qualified no-cache == qualified private, except that private only
applies to shared caches.

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

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

Why?

The original text for no-cache is fine imho.

> private, if there's support for that.

Why?

Cache-Control: private=Set-Cookie

makes a whole lot sense to support, and I see no reason why to deprecate
this.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Feb 2012 15:27:18 +1100

> applies to shared caches.

That's not how they're currently specified. 

Private says:

>       If the private response directive specifies one or more field-
>       with the listed response header fields.  That is, a shared cache
>       MUST NOT store the specified field-names(s), whereas it MAY store
>       the remainder of the response message.

>       fields in a response, while still allowing caching of the rest of

Notice that private is about whether the specific field-names can be stored, where no-cache is about validation. 

No-cache doesn't indicate whether the response can be served from cache without those headers, or whether it has to revalidate to check their values. 

These are two very different behaviours, which is why I think this is underspecified and an interop problem.

> not add any value, only confusion.

That note has been in there for quite some time, and was added based upon previous discussion.

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 21 Feb 2012 10:10:36 +0100

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.

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

> 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