Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/03/draft-ietf-httpbis-p6-cache-03.xml?rev=266
Timestamp: 2020-08-07 16:33:55
Document Index: 372523904

Matched Legal Cases: ['art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art4', 'art7', 'art1', 'art1', 'art3', 'art1', 'art5', 'art3', 'art1', 'art5', 'art2', 'art7', 'art1']

draft-ietf-httpbis-p6-cache-03.xml in draft-ietf-httpbis/03 – Hypertext Transfer Protocol Wiki
source: draft-ietf-httpbis/03/draft-ietf-httpbis-p6-cache-03.xml @ 266
Last change on this file since 266 was 264, checked in by julian.reschke@…, 12 years ago
<rfc obsoletes="2616" category="std" ipr="full3978" docName="draft-ietf-httpbis-p6-cache-03">
<date month="June" year="2008" day="17"/>
An HTTP cache is a local store of response messages
A cache behaves in a "semantically transparent" manner, with
Note: The server, cache, or client implementor might be faced with
DQUOTE = <DQUOTE, defined in [Part1], Section 2.2>
SP = <SP, defined in [Part1], Section 2.2>
field-name = <field-name, defined in [Part1], Section 4.2>
port = <port, defined in [Part1], Section 3.2.1>
pseudonym = <pseudonym, defined in [Part1], Section 8.9>
uri-host = <uri-host, defined in [Part1], Section 3.2.1>
A correct cache MUST respond to a request with the most up-to-date
MAY still return the response with the appropriate Warning
correct cache SHOULD respond as above if the response can be
correctly served from the cache; if not it MUST return an error or
cache SHOULD forward it to the requesting client without adding a new
SHOULD NOT attempt to revalidate a response simply because that
MAY display a warning indication to the user.
MUST attach a warning to that effect, using a Warning general-header.
Warnings MAY be used for other purposes, both cache-related and
indicates whether the Warning MUST or MUST NOT be deleted from a
the response, and so MUST be deleted after a successful
revalidation. 1xx warn-codes MAY be generated by a cache only when
validating a cached entry. It MUST NOT be generated by clients.</t>
lossy compression of the entity bodies) and which MUST NOT be
Warnings also carry a warning text. The text MAY be in any
headers), and include an OPTIONAL indication of what character set is
Multiple warnings MAY be attached to a response (either by the origin
max-stale=3600" to every request. The user agent SHOULD NOT
in abnormally ineffective caching, but MAY be explicitly configured
agent SHOULD explicitly indicate to the user whenever this results in
abnormally reduce the effectiveness of caches, the user agent SHOULD
In some cases, the operator of a cache MAY choose to configure it to
response, it MUST mark it as such (using a Warning header) enabling
fresh response. For this reason, a cache SHOULD NOT return a stale
A client's request MAY specify the maximum age it is willing to
the cache(s) to revalidate all responses. A client MAY also specify
A client MAY also specify that it will accept stale responses, up to
time in the future, indicating that a response MAY be used to satisfy
to validate every request, it MAY assign an explicit expiration time
cache SHOULD validate it before using it for subsequent requests. See
it is configured, to validate every request, it SHOULD use the "must-revalidate"
HTTP, but especially hosts running origin servers and caches, SHOULD
generated (see Section 8.3 of <xref target="Part1"/>). We use the term "date_value" to denote
<figure><artwork type="code"><![CDATA[
request was initiated. Then, when an Age value is received, it MUST
generated from a cache entry, the cache MUST include a single Age
does not include other restrictions on caching, the cache MAY compute
a freshness lifetime using a heuristic. The cache MUST attach Warning
expiration value SHOULD be no more than some fraction of the interval
response, then the client MAY ignore the response. If so, it MAY
different validators, it MUST use the one with the more recent Date
for the existing entry, then the client SHOULD repeat the request
If the Date values are equal, then the client MAY use either response
(or MAY, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to choose
HTTP's conditional request mechanism, defined in <xref target="Part4"/>, is
a validating GET request SHOULD be made conditional to those field values.
directive, a caching system MAY always store a successful response
(see <xref target="errors.or.incomplete.response.cache.behavior"/>) as a cache entry, MAY return it without validation
if it is fresh, and MAY return it after successful validation. If
certain caches MAY violate this expectation (for example, when little
Note: some HTTP/1.0 caches are known to violate this expectation
Note that Section 4.1 of <xref target="Part7"/> normally prevents a shared cache from saving
410 MAY be stored by a cache and used in reply to a subsequent
the Range and Content-Range headers MUST NOT cache 206 (Partial
and 307) MUST NOT be returned in a reply to a subsequent request
responses MUST be stored as part of a cache entry and MUST be
Other hop-by-hop headers MUST be listed in a Connection header
(Section 8.1 of <xref target="Part1"/>).
transparent proxy SHOULD NOT modify an end-to-end header unless the
A transparent proxy MUST NOT modify any of the following fields in a
request or response, and it MUST NOT add any of these fields if not
but it MAY add any of these fields if not already present. If an
Expires header is added, it MUST be given a field-value identical to
A proxy MUST NOT modify or add any of the following fields in a
A non-transparent proxy MAY modify or add these fields to a message
that does not include no-transform, but if it does so, it MUST add a
authentication mechanisms MAY rely on the values of header fields
according to the rules in Section 4.4 of <xref target="Part1"/>. A transparent proxy MUST
preserve the entity-length (Section 4.2.2 of <xref target="Part3"/>) of the entity-body,
although it MAY change the transfer-length (Section 4.4 of <xref target="Part1"/>).
Last-Modified headers match exactly, the cache MAY combine the
response, (see Section 5 of <xref target="Part5"/>).
MUST be deleted from the cache entry and the forwarded response.</t>
<t>any stored Warning headers with warn-code 2xx MUST be retained
<t>any end-to-end headers provided in the 304 or 206 response MUST
Unless the cache decides to remove the cache entry, it MUST also
cache entry, all such old headers MUST be replaced.
Note: this rule allows an origin server to use a 304 (Not
Use of server-driven content negotiation (Section 5.1 of <xref target="Part3"/>), as indicated
A server SHOULD use the Vary header field to inform a cache of what
the cache MUST NOT use such a cache entry to construct a response to
about message headers in Section 4.2 of <xref target="Part1"/>.
the cache MUST NOT use a cached entry to satisfy the request unless
forwarded request SHOULD be conditional and include the entity tags
entry, the new response SHOULD be used to update the header fields of
the existing entry, and the result MUST be returned to the client.
for the associated entity, its entity-tag SHOULD NOT be included in
existing entry SHOULD NOT be returned in response to future requests
and SHOULD be deleted from the cache.
in this case SHOULD be enforced by appropriate security mechanisms.
bytes of data than specified in a Content-Length header) MAY store
the response. However, the cache MUST treat this as a partial
response. Partial responses MAY be combined as described in Section 5 of <xref target="Part5"/>;
partial. A cache MUST NOT return a partial response to a client
Content) status code. A cache MUST NOT return a partial response
entry, it MAY either forward this response to the requesting client,
or act as if the server failed to respond. In the latter case, it MAY
SHOULD NOT have side effects that would lead to erroneous behavior if
these responses are taken from a cache. They MAY still have side
effects, caches MUST NOT treat responses to such URIs as fresh unless
means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
be taken from a cache. See Section 8.1.1 of <xref target="Part2"/> for related information.
Some HTTP methods MUST cause a cache to invalidate an entity. This is
on the URI in a Location or Content-Location header MUST NOT be
understand SHOULD invalidate any entities referred to by the
origin server's resources MUST be written through to the origin
A cache MUST NOT reply to such a request from a client before having
the same resource are cached, the cache SHOULD use the new response
to reply to the current request. It MAY insert it into cache storage
and MAY, if it meets all other requirements, use it to respond to any
Note: a new response that has an older Date header value than
mechanisms SHOULD NOT try to show a semantically transparent view of
If the entity is still in storage, a history mechanism SHOULD display
Note: if history list mechanisms unnecessarily prevent users from
<iref primary="true" item="Age header"/>
<iref primary="true" item="Headers" subitem="Age"/>
<figure><iref primary="true" item="Grammar" subitem="Age"/><iref primary="true" item="Grammar" subitem="age-value"/><artwork type="abnf2616"><![CDATA[
overflows, it MUST transmit an Age header with a value of
2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
own cache. Caches SHOULD use an arithmetic type of at least 31
<iref primary="true" item="Cache-Control header"/>
<iref primary="true" item="Headers" subitem="Cache-Control"/>
that MUST be obeyed by all caching mechanisms along the
Cache directives MUST be passed through by a proxy or gateway
<figure><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="cache-directive"/><iref primary="true" item="Grammar" subitem="cache-request-directive"/><iref primary="true" item="Grammar" subitem="cache-response-directive"/><iref primary="true" item="Grammar" subitem="cache-extension"/><artwork type="abnf2616"><![CDATA[
Cache-Control = "Cache-Control" ":" 1#cache-directive
"no-cache" ; Section 16.2.1
| "no-store" ; Section 16.2.2
| "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4
| "max-stale" [ "=" delta-seconds ] ; Section 16.2.3
| "min-fresh" "=" delta-seconds ; Section 16.2.3
| "no-transform" ; Section 16.2.5
| "only-if-cached" ; Section 16.2.4
| cache-extension ; Section 16.2.6
"public" ; Section 16.2.1
| "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
| "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
| "must-revalidate" ; Section 16.2.4
| "proxy-revalidate" ; Section 16.2.4
| "max-age" "=" delta-seconds ; Section 16.2.3
| "s-maxage" "=" delta-seconds ; Section 16.2.3
Indicates that the response MAY be cached by any cache, even if it
cache. (See also Authorization, Section 4.1 of <xref target="Part7"/>, for
a single user and MUST NOT be cached by a shared cache. This
MAY cache the response.
Note: This usage of the word private only controls where the
cache MUST NOT use the response to satisfy a subsequent request
then a cache MAY use the response to satisfy a subsequent request,
specified field-name(s) MUST NOT be sent in the response to a
Note: Most HTTP/1.0 caches will not recognize or obey this
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
a cache MUST NOT store any part of either this response or the
and shared caches. "MUST NOT store" in this context means
that the cache MUST NOT intentionally store the information in
non-volatile storage, and MUST make a best-effort attempt to
system (e.g., with a "Save As" dialog). History buffers MAY store
The expiration time of an entity MAY be specified by the origin
it MAY be specified using the max-age directive in a response. When
Cache-Control header field, it SHOULD consider the response to be
Note: An origin server might wish to use a relatively new HTTP
prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
mechanism. These directives MAY be specified on a request:
override the expiration time of a response, the cache MUST attach a
A cache MAY be configured to return stale responses without
names MUST NOT be included with the no-cache directive in a
request. The server MUST NOT use a cached copy when responding to
entry. In this case, the cache MAY use either validator in making
If a request includes the no-cache directive, it SHOULD NOT
this directive, a cache SHOULD either respond using a cached entry
connectivity, such a request MAY be forwarded within that group of
Because a cache MAY be configured to ignore a server's specified
expiration time, and because a client request MAY include a max-stale
MUST NOT use the entry after it becomes stale to respond to a
server. (I.e., the cache MUST do an end-to-end revalidation every
HTTP/1.1 cache MUST obey the must-revalidate directive; in
reason, it MUST generate a 504 (Gateway Timeout) response.
Servers SHOULD send the must-revalidate directive if and only if
transaction. Recipients MUST NOT take any automated action that
violates this directive, and MUST NOT automatically provide an
severe connectivity constraints MAY violate this directive but, if
so, MUST explicitly warn the user that an unvalidated response has
been provided. The warning MUST be provided on each unvalidated
access, and SHOULD require explicit user confirmation.
intermediate cache or proxy MUST NOT change those headers that are
directive. This implies that the cache or proxy MUST NOT change
cache behavior) MAY be added without changing the semantics of other
Unrecognized cache-directives MUST be ignored; it is assumed that any
<iref primary="true" item="Expires header"/>
<iref primary="true" item="Headers" subitem="Expires"/>
Section 3.3.1 of <xref target="Part1"/>; it MUST be sent in rfc1123-date format.
<figure><iref primary="true" item="Grammar" subitem="Expires"/><artwork type="abnf2616"><![CDATA[
Note: if a response includes a Cache-Control field with the max-age
HTTP/1.1 clients and caches MUST treat other invalid date formats,
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
<iref primary="true" item="Pragma header"/>
<iref primary="true" item="Headers" subitem="Pragma"/>
MAY require that behavior be consistent with the directives.
<figure><iref primary="true" item="Grammar" subitem="Pragma"/><iref primary="true" item="Grammar" subitem="pragma-directive"/><iref primary="true" item="Grammar" subitem="extension-pragma"/><artwork type="abnf2616"><![CDATA[
Pragma = "Pragma" ":" 1#pragma-directive
application SHOULD forward the request toward the origin server even
HTTP/1.0. Clients SHOULD include both header fields when a no-cache
Pragma directives MUST be passed through by a proxy or gateway
recipient SHOULD be ignored by that recipient.
Note: because the meaning of "Pragma: no-cache" as a
<iref primary="true" item="Vary header"/>
<iref primary="true" item="Headers" subitem="Vary"/>
<figure><iref primary="true" item="Grammar" subitem="Vary"/><artwork type="abnf2616"><![CDATA[
An HTTP/1.1 server SHOULD include a Vary header field with any
on that resource. A server MAY include a Vary header field with a
in selecting the most appropriate representation. A cache MAY assume
The "*" value MUST NOT be generated by a proxy server; it may only be
<iref primary="true" item="Warning header"/>
<iref primary="true" item="Headers" subitem="Warning"/>
<figure><iref primary="true" item="Grammar" subitem="Warning"/><iref primary="true" item="Grammar" subitem="warning-value"/><iref primary="true" item="Grammar" subitem="warn-code"/><iref primary="true" item="Grammar" subitem="warn-agent"/><iref primary="true" item="Grammar" subitem="warn-text"/><iref primary="true" item="Grammar" subitem="warn-date"/><artwork type="abnf2616"><![CDATA[
Warning = "Warning" ":" 1#warning-value
warn-agent = ( uri-host [ ":" port ] ) | pseudonym
The warn-text SHOULD be in a natural language and character set that
response. This decision MAY be based on any available knowledge, such
If a character set other than ISO-8859-1 is used, it MUST be encoded
applied to response messages. New Warning headers SHOULD be added
after any existing Warning headers. A cache MUST NOT delete any
successfully validates a cache entry, it SHOULD remove any Warning
specific Warning codes. It MUST then add any Warning headers received
inform the user of all of the warnings, the user agent SHOULD follow
Systems that generate multiple Warning headers SHOULD order them with
MUST be included whenever the returned response is stale.
MUST be included if a cache returns a stale response because an
SHOULD be included if the cache is intentionally disconnected from
MUST be included if the cache heuristically chose a freshness
The warning text MAY include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST NOT
MUST be added by an intermediate cache or proxy if it applies any
whose version is HTTP/1.0 or lower, then the sender MUST include in
value in the response, then that warning-value MUST be deleted from
MUST be deleted as well.
<date month="June" year="2008"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-03"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-03"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-03"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-03"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-03"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-03"/>
Get rid of duplicate BNF rule names ("host" -&gt; "uri-host")