Re: Major errors in Caching and Cache-Control

Since Roy has complained several times about the Cache-control
section, I guess I owe him a response ... even though I agree
with Larry that the timing is a little odd, and phrases such as
"irreparable harm" are not exactly substantiated.

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

If there is supposed to be an extension mechanism (beyond
the 1#field-name parameters to private and no-cache, which
are still there), please describe it!

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

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.

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

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

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

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

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

-Jeff

Received on Monday, 3 June 1996 14:53:03 UTC