Re: CHANGES to 14.9 Cache-Control

All of these suggestions to 14.9 (below) look good to me.

......Roy
=======================================================
> 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 12:37:33 UTC