Major errors in Caching and Cache-Control

I do not feel that the sections on Caching and Cache-Control have
had adequate review.  Scratch that -- I am sure that they have not
been adequately reviewed, since they contain multiple protocol
errors, inconsistency, and violation of basic HTTP design principles.

Five of the cache directives in draft 04a have never been discussed
on any public mailing list (including this one and that of the
caching subgroup), and I have no idea if implementers will be willing
to implement them (unlike the other directives, for which we obtained
consensus before introducing them to the draft).

Just a cursory examination is enough to determine that

   Cache-Control is incorrectly defined because somebody removed
     the extension mechanism.  THIS IS FATAL.

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

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

   "only-if-cached"
      is not really a cache directive (it is a request modifier and thus
      should be in a request-header field),

   "no-store"
      serves no useful purpose and should be deleted,

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

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

All of the FATAL problems above must be rectified before this
specification can be a proposed standard -- they would cause
irreparable harm otherwise.  This is worth delaying the specification
by a few days, if necessary -- there is no way to avoid it.

I suggest we submit a revised draft right now (containing all of the
changes to 04a that have already been mentioned) and that we then
immediately fix the caching sections while others are proof-checking
the real draft 04.


 ...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 Monday, 3 June 1996 10:26:31 UTC