Re: Cache-Control directive, semantics

Regarding the apparent contradiction between 14.8 and 14.9.4 over
the meaning of proxy-revalidate:

    >I think we've agreed that this is a bug in the specification.  That
	     ^^^^^^^^^^^^ 
    >is, we did not intend that the meaning of this cache-control directive
    >should change when another response header is present.
    
    For the record, if you are using the word `bug' not just to mean `we
    intended it differently', but also to mean `this is a fatal problem
    that must be fixed', I do _not_ agree that this is a bug in the
    specification.  In my reading, 14.8 does *not* modify or contradict
    14.9.4.
    
    14.9.4 talks about restrictions implied by proxy-revalidate.  
    14.8 talks about restrictions implied by the Authorization header
    which happen to be _lifted_ when proxy-revalidate is present.

Well, we *did* intend it differently, as Paul Leach has reminded
me, although the most serious consequence of this is for the
digest-authentication stuff.

It is true that one could read the language in 14.8 as being a
modification of the meaning of 14.9.4, although in that case I would
have to admit that I wrote a confusing and non-orthogonal
specification. for this directive.

But in fact, when I wrote these two paragraphs, I had different
(and incompatible) meanings in my own head for the same directive,
and so that's why I feel confident calling it a bug.  It was my
error, so I get to say what kind of error it is! :-)  (More to
the point, what I wrote does conflict with what the editorial
group wanted to see.)

-Jeff

Received on Thursday, 2 January 1997 11:32:46 UTC