Re: CHANGES to 14.9 Cache-Control

Generally OK with me, but I have a few minor corrections to
propose:

*************
    ! 14.9.1 What is Cachable
      
      public 
    !   Indicates that the response is cachable by any cache, even if it would
    !   normally be non-cachable or cachable only within a non-shared cache.

I strongly suggest restoring the cross-reference to section 14.8.  How
about:
      public 
        Indicates that the response is cachable by any cache, even if it would
        normally be non-cachable or cachable only within a non-shared cache.
	(See section 14.8 for additional details.)

*************
      max-stale
	Indicates that the client is willing to accept a response that has
    !   exceeded its expiration time. If max-stale is assigned a value, then
    !   the client is willing to accept a response that has exceeded its
    !   expiration time by no more than the specified number of seconds.
    !   If no value is assigned to max-stale, then it should be considered
    !   infinite (i.e., any response is okay).
      
I think "any response is okay" fails to clarify this; it might actually
make it less clear.

How about changing the last sentence to:
	If no value is assigned to max-stale, then the client is
	willing to accept a stale response of any age.

*************

Regarding:

    + 14.9.6 Cache Control Extensions
    + 
    + The Cache-Control header field can be extended through the use of one or
    + more cache-extension tokens, each with an optional assigned value.
    + Informational extensions (those which do not require a change in cache
    + behavior) may be added without changing the semantics of other
    + directives. Behavioral extensions are designed to work by acting as
    + modifiers to the existing base of cache directives. Both the new
    + directive and the standard directive are supplied, such that
    + applications which do not understand the new directive will default to
    + the behavior specified by the standard directive, and those that
    + understand the new directive will recognize it as modifying the
    + requirements associated with the standard directive.  In this way,
    + extensions to the Cache-Control directives can be made without requiring
    + changes to the base protocol.

I think it might be helpful and clearer to state explicitly what we
discussed in yesterday's teleconference as the principle behind this
design (and behind the removal of min-vers):

	This extension mechanism depends on the fact that an HTTP
	cache obeys all of the cache-control directives defined
	for its native HTTP-version, may obey certain extensions,
	and ignores all directives that it does not understand.

Also, in
    + For example, let's consider a hypothetical new response directive called
I think we could remove the "let's" and make the tone more consistent
with the rest of the document.

*************

Finally, I note that the revised wording for Cache-Control no longer
warns implementors that HTTP/1.0 caches do not necessarily obey
*any* of the cache-control directives.  Also, draft-04 omits the
suggestion in draft-03 (somewhat awkwardly listed under "16.12
Generic Resources and HTTP/1.0 Proxy Caches") that an origin server
can exploit the precedence relationship between Expires: and
Cache-Control: max-age to prevent allow caching by HTTP/1.1-compliant
caches while preventing possibly erroneous caching by older caches.

So I propose adding this note to section 14.9, after the second
paragraph:

	Note: most older caches, not compliant with HTTP/1.1, do
	not implement any Cache-Control directives.  An origin
	server wishing to use a Cache-Control directive that
	restricts, but does not prevent, caching by an
	HTTP/1.1-compliant cache may exploit the requirement
	that the max-age directive overrides the Expires header,
	and the fact that non-HTTP/1.1-compliant caches do not
	observe the max-age directive.

This is, after all, an entirely analogous situation to the
extension mechanism Roy described for Cache-control, does not
change any normative aspect of the draft, and so I don't expect
any objections.

-Jeff

Received on Friday, 7 June 1996 11:42:44 UTC