- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Thu, 06 Jun 1996 16:39:04 -0700
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: jg@w3.org
Here are my proposed changes for Cache-Control. I have not changed
the descriptions of "no-store" (which somebody else is doing) and
"no-transform" (which Jim already did).
These changes were discussed in the teleconference. I have created
a new section (and modified the BNF) to restore the extension mechanism
that was in Pragma and which I forgot to copy in draft 00. I also
changed the BNF for max-stale such that no value means infinity, and
simplified the description of cachability to point to the section that
will be in Caching. Finally, I removed "min-vers" since it is no
longer necessary given the extension mechanism description.
Please ignore the diff line numbers -- these are all in Section 14.9.
=========================================
*** Rev84.txt Tue Jun 4 06:47:45 1996
--- cc1 Thu Jun 6 16:07:40 1996
***************
*** 5461,5647 ****
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
! | "max-stale" "=" delta-seconds
| "min-fresh" "=" delta-seconds
- | "min-vers" "=" HTTP-Version
| "only-if-cached"
cache-response-directive =
"public"
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
! | "min-vers" "=" HTTP-Version
--- 5461,5596 ----
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
! | "max-stale" [ "=" delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
+ | cache-extension
cache-response-directive =
"public"
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
! | cache-extension
+
+ cache-extension = token [ "=" ( token | quoted-string ) ]
***************
*** 5655,5687 ****
! 14.9.1 Cache-Control Restrictions on What is Cachable
- Unless specifically constrained by a Cache-Control directive, a caching
- system may always store a successful response (see section 13.7) as a
- cache entry, may return it without validation if it is fresh, and may
- return it after successful validation. If there is neither a cache
- validator nor an explicit expiration time associated with a response, we
- do not expect it to be cached, but certain caches may violate this
- expectation (for example, when little or no network connectivity is
- available). A client can usually detect that such a response was taken
- from a cache by comparing the Date header to the current time.
-
- Note that some HTTP/1.0 caches are known to violate this
- expectation without providing any Warning.
-
- However, in some cases it may be inappropriate for a cache to retain a
- entity, or to return it in response to a subsequent request. This may be
- because absolute semantic transparency is deemed necessary by the
- service author, or because of security or privacy considerations.
- Certain Cache-Control directives are therefore provided so that the
- server can indicate that certain resource entities, or portions thereof,
- may not be cached regardless of other considerations.
-
- Note that section 14.8 normally prevents a shared cache from saving and
- returning a response to a previous request if that request included an
- Authorization header.
-
! The following Cache-Control response directives add or remove
! restrictions on what is cachable:
!
public
! Overrides the restriction in section 14.8 that prevents a shared
! cache from saving and returning a response to a previous request if
! that request included an Authorization header. However, any other
! constraints on caching still apply.
private
Indicates that all or part of the response message is intended for a
single user and MUST NOT be cached by a shared cache. This allows an
origin server to state that the specified parts of the response are
intended for only one user and are not a valid response for requests
! by other users. A private (non-shared) cache may ignore this
! directive.
Note: This usage of the word private only controls where the
response may be cached, and cannot ensure the privacy of the
! message content. Note in particular that HTTP/1.0 caches will not
! recognize or obey this directive.
no-cache
! indicates that all or part of the response message MUST NOT be cached
anywhere. This allows an origin server to prevent caching even by
caches that have been configured to return stale responses to client
requests.
- Note: HTTP/1.0 caches will not recognize or obey this directive.
--- 5461,5596 ----
! 14.9.1 What is Cachable
! By default, a response is cachable if the requirements of the request
! method, request header fields, and the response status indicate that it
! is cachable. Section 13.?? summarizes these defaults for cachability.
! The following Cache-Control response directives allow an origin server
! to override the default cachability of a response:
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.
private
Indicates that all or part of the response message is intended for a
single user and MUST NOT be cached by a shared cache. This allows an
origin server to state that the specified parts of the response are
intended for only one user and are not a valid response for requests
! by other users. A private (non-shared) cache may cache the response.
Note: This usage of the word private only controls where the
response may be cached, and cannot ensure the privacy of the
! message content.
no-cache
! Indicates that all or part of the response message MUST NOT be cached
anywhere. This allows an origin server to prevent caching even by
caches that have been configured to return stale responses to client
requests.
***************
*** 5655,5687 ****
14.9.2 What May be Stored by Caches
The no-store directive applies to the entire message, and may be sent
either in a response or in a request. If sent in a request, a cache MUST
NOT store any part of either this request or any response to it. If sent
in a response, a cache MUST NOT store any part of either this response
or the request that elicited it. This directive applies to both non-
shared and shared caches.
Even when this directive is associated with a response, users may
explicitly store such a response outside of the caching system (e.g.,
with a "Save As" dialog). History buffers may store such responses as
part of their normal operation.
The purpose of this directive is to meet the stated requirements of
certain users and service authors who are concerned about accidental
releases of information via unanticipated accesses to cache data
structures. While the use of this directive may improve privacy in some
cases, we caution that it is NOT in any way a reliable or sufficient
! mechanism for ensuring privacy. In particular, HTTP/1.0 caches will not
! recognize or obey this directive; malicious or compromised caches may
! not recognize or obey this directive; and communications networks may be
! vulnerable to eavesdropping.
- The min-vers directive applies to the entire message, and may be sent
- either in a response or in a request. If sent in a request, a cache
- whose HTTP version number is less than the specified version MUST NOT
- store any part of either this request or any response to it. If sent in
- a response, a cache whose HTTP version number is less than the specified
- version MUST NOT store any part of either this response or the request
- that elicited it, nor may any cache transmit a stored (non-first-hand)
- copy of the response to any client with a lower HTTP version number.
- This directive applies to both non-shared and shared caches, and is made
- mandatory to allow for future protocol extensions that may affect
- caching.
- Note that the lowest version that can be sensibly included in a
- min-vers directive is HTTP/1.1, since HTTP/1.0 caches do not obey
- it.
-
-
14.9.3 Modifications of the Basic Expiration Mechanism
! The expiration time of a entity may be specified by the origin server
using the Expires header (see section 14.21). Alternatively, it may be
specified using the max-age directive in a response.
--- 5461,5596 ----
14.9.2 What May be Stored by Caches
The no-store directive applies to the entire message, and may be sent
either in a response or in a request. If sent in a request, a cache MUST
NOT store any part of either this request or any response to it. If sent
in a response, a cache MUST NOT store any part of either this response
or the request that elicited it. This directive applies to both non-
shared and shared caches.
Even when this directive is associated with a response, users may
explicitly store such a response outside of the caching system (e.g.,
with a "Save As" dialog). History buffers may store such responses as
part of their normal operation.
The purpose of this directive is to meet the stated requirements of
certain users and service authors who are concerned about accidental
releases of information via unanticipated accesses to cache data
structures. While the use of this directive may improve privacy in some
cases, we caution that it is NOT in any way a reliable or sufficient
! mechanism for ensuring privacy. In particular, malicious or compromised
! caches may not recognize or obey this directive, and communications
! networks may be vulnerable to eavesdropping.
14.9.3 Modifications of the Basic Expiration Mechanism
! The expiration time of an entity may be specified by the origin server
using the Expires header (see section 14.21). Alternatively, it may be
specified using the max-age directive in a response.
***************
*** 5655,5687 ****
[14.9.3 Modifications of the Basic Expiration Mechanism] ...
max-stale
Indicates that the client is willing to accept a response that has
! exceeded its expiration time by no more than the specified number of
! seconds. If a cache returns a stale response in response to such a
! request, it MUST mark it as stale using the Warning header.
If a cache returns a stale response, either because of a max-stale
directive on a request, or because the cache is configured to override
the expiration time of a response, the cache MUST attach a Warning
header to the stale response, using Warning 10 (Response is stale).
--- 5604,5638 ----
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).
If a cache returns a stale response, either because of a max-stale
directive on a request, or because the cache is configured to override
the expiration time of a response, the cache MUST attach a Warning
header to the stale response, using Warning 10 (Response is stale).
***************
*** 5759,5789 ****
[14.9.4 Cache Revalidation and Reload Controls ...]
Because a cache may be configured to ignore a server's specified
expiration time, and because a client request may include a max-stale
! directive, which has a similar effect, the protocol also includes a
mechanism for the origin server to require revalidation of a cache entry
on any subsequent use. When the must-revalidate directive is present in
--- 5710,5740 ----
Because a cache may be configured to ignore a server's specified
expiration time, and because a client request may include a max-stale
! directive (which has a similar effect), the protocol also includes a
mechanism for the origin server to require revalidation of a cache entry
on any subsequent use. When the must-revalidate directive is present in
***************
*** 5804,5833 ****
--- 5755,5822 ----
+
+ 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.
+
+ For example, let's consider a hypothetical new response directive called
+ "community" which acts as a modifier to the "private" directive. We
+ define this new directive to mean that, in addition to any non-shared
+ cache, any cache which is shared only by members of the community named
+ within its value may cache the response. An origin server wishing to
+ allow the "UCI" community to use an otherwise private response in their
+ shared cache(s) may do so by including
+
+ Cache-Control: private, community="UCI"
+
+ A cache seeing this header field will act correctly even if the cache
+ does not understand the "community" cache-extension, since it will also
+ see and understand the "private" directive and thus default to the safe
+ behavior.
+
+ Unrecognized cache-directives MUST be ignored; it is assumed that any
+ cache-directive likely to be unrecognized by an HTTP/1.1 cache will be
+ combined with standard directives (or the response's default cachability)
+ such that the cache behavior will remain minimally correct even if the
+ cache does not understand the extension(s).
14.10 Connection
***************
end-of-diff
...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 Thursday, 6 June 1996 17:28:08 UTC