Re: Major errors in Caching and Cache-Control

>    Cache-Control is incorrectly defined because somebody removed
>      the extension mechanism.  THIS IS FATAL.
> 
> Begging your pardon, but what "extension mechanism"?  I looked
> at draft-ietf-http-v11-spec-01.txt, and the BNF that you wrote
> there says:
> 
>        Cache-Control   = "Cache-Control" ":" 1#cache-directive
> 
>        cache-directive = "cachable"
>                        | "max-age" "=" delta-seconds
>                        | "private" [ "=" <"> 1#field-name <"> ]
>                        | "no-cache" [ "=" <"> 1#field-name <"> ]
> 
> and 10.8 (in that draft) does not included the string "exten*".

That means I screwed-up when I moved the directives from Pragma to
Cache-Control. Sorry. The extension mechanism is along the lines of

                         | extension-directive

     extension-directive = token [ "=" word ]

I'll write up a section to explain how it works.  In short, a new
directive is added in parallel with existing directives (i.e., if
we wanted to define a new state of cachability in-between no-cache
and private, called "fred", then we would send

     Cache-Control: no-cache, fred

Caches that don't understand fred will understand no-cache and will thus
behave as the safe default; those that do understand fred will know
that it modifies the interpretation of no-cache and will behave as desired.

I'll include a real example in the real description.

>    "max-stale"
>       is defined incorrectly.  It is supposed to allow
>           "max-stale" [ = delta-seconds ]
>       where the absence of a specific value means infinity,
>       as was the consensus in the caching subgroup.  THIS IS FATAL.
> 
> FATAL?  Hardly.  "max-stale=2147483648" is a reasonably approximation
> of infinity, is allowed by the BNF, and when I proposed this on
> the http-caching mailing list, you did not object.

Yes I did -- several times. We even talked about it in LA.  Hell, someone
even wrote a paper about caching at WWW5 in which they pointed out the
need for a max=age=infinity (and I told them it was already defined
and was left out of draft 02 by accident).

> However, if you want to save a few bytes on the wire in exchange
> for a more elaborate parsing problem, I have no objections to this
> change.

The reason for the difference is not just to save bytes -- it is to
explicitly indicate that the user wants anything available, no matter
how stale.  That may change the actions of some caches, particularly
within controlled administrative domains.

>    "min-vers"
>       is contrary to the design of Cache-Control, where extensions
>       are added as modifiers to existing directives and not by complete
>       override of all directives, and most certainly not by tying it
>       to a particular protocol version.  THIS IS FATAL.
> 
> This is dogma masquerading as a design principle.  Is min-vers
> useful or not?  If not, why not?  If it is, what possible harm
> comes from associating with cache-control (since it's an explicit
> restriction on *cache* operation, not on anything else)?
> 
> Anyway, I think our current experience with trying to design a
> compatible-but-improved protocol suggests that this EXTENSIBILITY
> MECHANISM (had to get that in there, sorry) is of great potential
> value.

That isn't an extensibility mechanism -- anything that requires putting
together an IETF WG, writing a spec, building consensus, and then getting
it adopted as a new proposed standard does not qualify as extensibility.

Caching is independent of the protocol version -- in fact, it is mostly
independent of the protocol (upgrading to HTTP/2.0 will not affect the
basic caching requirements, only how they are expressed in the syntax).
Including a mechanism that disables existing caches just to add a new
tweak to the protocol is fundamentally wrong and contrary to the design
of HTTP.

If we had something like min-vers, then the values would be better
defined as just 1, 2, 3, 4, ... (with 1 being HTTP/1.1, 2 being the
next time caching was changed, etc.).  In any case, this is paltry
compared to a real design for extensibility.

>    "only-if-cached"
>       is not really a cache directive (it is a request modifier and thus
>       should be in a request-header field),
> 
> To my mind, it's as reasonable to put this into cache-control as, say,
> max-age; it discusses only the relationship of the request to an
> intermediate cache, and not the underlying semantics of the request.

Okay, that seems reasonable.  I think the descriptions in Cache-Control
could be rephrased (or at least organized) so that it is easier to find
the definition of each directive.  I'll think some on that.

>    "no-store"
>       serves no useful purpose and should be deleted,
> 
> We discussed this at length on the http-caching mailing list,
> and several people insisted that their customers required it.

My recollection is that just the two of us discussed it.  You asked why
I explicitly mentioned storage in "no-cache".  I described the discussion
I had with Lou Montulli on http-wg about no-cache implying that the
application should not store the entity (and maybe satisfying some people's
security needs).  We then discussed the notion of having "no-store" mean that
no application is allowed to store the information on disk, but decided
that wasn't appropriate for cache-control and is better left for PEP.
And that's why it shouldn't be in the draft any more.

>    "no-transform"
>       is completely wrong because it talks about content codings
>       in a way that only transfer codings are allowed to behave, and
>       thus CONTRADICTS other sections.  THIS IS FATAL (and isn't needed).
> 
> Please discuss the wording with the Digest Authentication folks,
> who believed that this was a necessary feature.

The whole concept is wrong -- no cache is ever allowed to change the
entity content-coding.  The only thing allowed is transfer coding
between hops, and that won't affect digest.

>    "must-validate" and "proxy-validate"
>       would be better replaced by a single "vital" directive which
>       applies to all cache requirements (like Shel asked for a long
>       time ago) and thus would be extensible as well.
> 
> This fails to address some of the issues raised (perhaps in
> private email, I'm not sure) by the Digest Authentication folks.

I am not aware of anything that would prevent a general requirement
like "vital" from replacing anything like must-*.  I could live with
just one redundant directive, but two speaks of a bad abstraction.
I will have a look at the archive later (I'm downloading it from the
UK right now).

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 4 June 1996 07:36:48 UTC