aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt')
-rw-r--r--vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt2352
1 files changed, 2352 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt
new file mode 100644
index 000000000..35b875615
--- /dev/null
+++ b/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt
@@ -0,0 +1,2352 @@
+
+
+
+HTTPbis Working Group R. Fielding, Ed.
+Internet-Draft Day Software
+Obsoletes: 2616 (if approved) J. Gettys
+Intended status: Standards Track Alcatel-Lucent
+Expires: February 5, 2011 J. Mogul
+ HP
+ H. Frystyk
+ Microsoft
+ L. Masinter
+ Adobe Systems
+ P. Leach
+ Microsoft
+ T. Berners-Lee
+ W3C/MIT
+ Y. Lafon, Ed.
+ W3C
+ M. Nottingham, Ed.
+
+ J. Reschke, Ed.
+ greenbytes
+ August 4, 2010
+
+
+ HTTP/1.1, part 6: Caching
+ draft-ietf-httpbis-p6-cache-11
+
+Abstract
+
+ The Hypertext Transfer Protocol (HTTP) is an application-level
+ protocol for distributed, collaborative, hypermedia information
+ systems. This document is Part 6 of the seven-part specification
+ that defines the protocol referred to as "HTTP/1.1" and, taken
+ together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
+ caches and the associated header fields that control cache behavior
+ or indicate cacheable response messages.
+
+Editorial Note (To be removed by RFC Editor)
+
+ Discussion of this draft should take place on the HTTPBIS working
+ group mailing list (ietf-http-wg@w3.org). The current issues list is
+ at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
+ documents (including fancy diffs) can be found at
+ <http://tools.ietf.org/wg/httpbis/>.
+
+ The changes in this draft are summarized in Appendix C.12.
+
+Status of This Memo
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 1]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 5, 2011.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 2]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
+ 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
+ 1.4.2. ABNF Rules defined in other Parts of the
+ Specification . . . . . . . . . . . . . . . . . . . . 7
+ 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7
+ 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
+ 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
+ 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
+ 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
+ 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
+ 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
+ 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
+ 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
+ 2.6. Shared Caching of Authenticated Responses . . . . . . . . 15
+ 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16
+ 2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 16
+ 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
+ 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
+ 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
+ 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
+ 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
+ 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
+ 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 28
+ 5.2. Header Field Registration . . . . . . . . . . . . . . . . 29
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
+ Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 31
+ Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
+ Appendix C. Change Log (to be removed by RFC Editor before
+ publication) . . . . . . . . . . . . . . . . . . . . 33
+ C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
+ C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
+ C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
+ C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
+ C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
+ C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34
+ C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
+ C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 3]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35
+ C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 36
+ C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 36
+ C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 37
+ Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 4]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+1. Introduction
+
+ HTTP is typically used for distributed information systems, where
+ performance can be improved by the use of response caches. This
+ document defines aspects of HTTP/1.1 related to caching and reusing
+ response messages.
+
+1.1. Purpose
+
+ An HTTP cache is a local store of response messages and the subsystem
+ that controls its message storage, retrieval, and deletion. A cache
+ stores cacheable responses in order to reduce the response time and
+ network bandwidth consumption on future, equivalent requests. Any
+ client or server MAY employ a cache, though a cache cannot be used by
+ a server that is acting as a tunnel.
+
+ Caching would be useless if it did not significantly improve
+ performance. The goal of caching in HTTP/1.1 is to reuse a prior
+ response message to satisfy a current request. In some cases, a
+ stored response can be reused without the need for a network request,
+ reducing latency and network round-trips; a "freshness" mechanism is
+ used for this purpose (see Section 2.3). Even when a new request is
+ required, it is often possible to reuse all or parts of the payload
+ of a prior response to satisfy the request, thereby reducing network
+ bandwidth usage; a "validation" mechanism is used for this purpose
+ (see Section 2.4).
+
+1.2. Terminology
+
+ This specification uses a number of terms to refer to the roles
+ played by participants in, and objects of, HTTP caching.
+
+ cacheable
+
+ A response is cacheable if a cache is allowed to store a copy of
+ the response message for use in answering subsequent requests.
+ Even when a response is cacheable, there might be additional
+ constraints on whether a cache can use the cached copy to satisfy
+ a particular request.
+
+ explicit expiration time
+
+ The time at which the origin server intends that a representation
+ no longer be returned by a cache without further validation.
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 5]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ heuristic expiration time
+
+ An expiration time assigned by a cache when no explicit expiration
+ time is available.
+
+ age
+
+ The age of a response is the time since it was sent by, or
+ successfully validated with, the origin server.
+
+ first-hand
+
+ A response is first-hand if the freshness model is not in use;
+ i.e., its age is 0.
+
+ freshness lifetime
+
+ The length of time between the generation of a response and its
+ expiration time.
+
+ fresh
+
+ A response is fresh if its age has not yet exceeded its freshness
+ lifetime.
+
+ stale
+
+ A response is stale if its age has passed its freshness lifetime
+ (either explicit or heuristic).
+
+ validator
+
+ A protocol element (e.g., an entity-tag or a Last-Modified time)
+ that is used to find out whether a stored response has an
+ equivalent copy of a representation.
+
+ shared cache
+
+ A cache that is accessible to more than one user. A non-shared
+ cache is dedicated to a single user.
+
+1.3. Requirements
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ An implementation is not compliant if it fails to satisfy one or more
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 6]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ of the "MUST" or "REQUIRED" level requirements for the protocols it
+ implements. An implementation that satisfies all the "MUST" or
+ "REQUIRED" level and all the "SHOULD" level requirements for its
+ protocols is said to be "unconditionally compliant"; one that
+ satisfies all the "MUST" level requirements but not all the "SHOULD"
+ level requirements for its protocols is said to be "conditionally
+ compliant".
+
+1.4. Syntax Notation
+
+ This specification uses the ABNF syntax defined in Section 1.2 of
+ [Part1] (which extends the syntax defined in [RFC5234] with a list
+ rule). Appendix B shows the collected ABNF, with the list rule
+ expanded.
+
+ The following core rules are included by reference, as defined in
+ [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
+ (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
+ HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
+ sequence of data), SP (space), VCHAR (any visible USASCII character),
+ and WSP (whitespace).
+
+1.4.1. Core Rules
+
+ The core rules below are defined in Section 1.2.2 of [Part1]:
+
+ quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
+ token = <token, defined in [Part1], Section 1.2.2>
+ OWS = <OWS, defined in [Part1], Section 1.2.2>
+
+1.4.2. ABNF Rules defined in other Parts of the Specification
+
+ The ABNF rules below are defined in other parts:
+
+ field-name = <field-name, defined in [Part1], Section 3.2>
+ HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
+ port = <port, defined in [Part1], Section 2.6>
+ pseudonym = <pseudonym, defined in [Part1], Section 9.9>
+ uri-host = <uri-host, defined in [Part1], Section 2.6>
+
+2. Cache Operation
+
+2.1. Response Cacheability
+
+ A cache MUST NOT store a response to any request, unless:
+
+ o The request method is understood by the cache and defined as being
+ cacheable, and
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 7]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ o the response status code is understood by the cache, and
+
+ o the "no-store" cache directive (see Section 3.2) does not appear
+ in request or response headers, and
+
+ o the "private" cache response directive (see Section 3.2.2 does not
+ appear in the response, if the cache is shared, and
+
+ o the "Authorization" header (see Section 3.1 of [Part7]) does not
+ appear in the request, if the cache is shared, unless the response
+ explicitly allows it (see Section 2.6), and
+
+ o the response either:
+
+ * contains an Expires header (see Section 3.3), or
+
+ * contains a max-age response cache directive (see
+ Section 3.2.2), or
+
+ * contains a s-maxage response cache directive and the cache is
+ shared, or
+
+ * contains a Cache Control Extension (see Section 3.2.3) that
+ allows it to be cached, or
+
+ * has a status code that can be served with heuristic freshness
+ (see Section 2.3.1.1).
+
+ In this context, a cache has "understood" a request method or a
+ response status code if it recognises it and implements any cache-
+ specific behaviour. In particular, 206 Partial Content responses
+ cannot be cached by an implementation that does not handle partial
+ content (see Section 2.1.1).
+
+ Note that in normal operation, most caches will not store a response
+ that has neither a cache validator nor an explicit expiration time,
+ as such responses are not usually useful to store. However, caches
+ are not prohibited from storing such responses.
+
+2.1.1. Storing Partial and Incomplete Responses
+
+ A cache that receives an incomplete response (for example, with fewer
+ bytes of data than specified in a Content-Length header) can store
+ the response, but MUST treat it as a partial response [Part5].
+ Partial responses can be combined as described in Section 4 of
+ [Part5]; the result might be a full response or might still be
+ partial. A cache MUST NOT return a partial response to a client
+ without explicitly marking it as such using the 206 (Partial Content)
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 8]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ status code.
+
+ A cache that does not support the Range and Content-Range headers
+ MUST NOT store incomplete or partial responses.
+
+2.2. Constructing Responses from Caches
+
+ For a presented request, a cache MUST NOT return a stored response,
+ unless:
+
+ o The presented effective request URI (Section 4.3 of [Part1]) and
+ that of the stored response match, and
+
+ o the request method associated with the stored response allows it
+ to be used for the presented request, and
+
+ o selecting request-headers nominated by the stored response (if
+ any) match those presented (see Section 2.7), and
+
+ o the presented request and stored response are free from directives
+ that would prevent its use (see Section 3.2 and Section 3.4), and
+
+ o the stored response is either:
+
+ * fresh (see Section 2.3), or
+
+ * allowed to be served stale (see Section 2.3.3), or
+
+ * successfully validated (see Section 2.4).
+
+ When a stored response is used to satisfy a request without
+ validation, caches MUST include a single Age header field
+ (Section 3.1) in the response with a value equal to the stored
+ response's current_age; see Section 2.3.2.
+
+ Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST
+ be written through the cache to the origin server; i.e., a cache must
+ not reply to such a request before having forwarded the request and
+ having received a corresponding response.
+
+ Also, note that unsafe requests might invalidate already stored
+ responses; see Section 2.5.
+
+ Caches MUST use the most recent response (as determined by the Date
+ header) when more than one suitable response is stored. They can
+ also forward a request with "Cache-Control: max-age=0" or "Cache-
+ Control: no-cache" to disambiguate which response to use.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 9]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+2.3. Freshness Model
+
+ When a response is "fresh" in the cache, it can be used to satisfy
+ subsequent requests without contacting the origin server, thereby
+ improving efficiency.
+
+ The primary mechanism for determining freshness is for an origin
+ server to provide an explicit expiration time in the future, using
+ either the Expires header (Section 3.3) or the max-age response cache
+ directive (Section 3.2.2). Generally, origin servers will assign
+ future explicit expiration times to responses in the belief that the
+ representation is not likely to change in a semantically significant
+ way before the expiration time is reached.
+
+ If an origin server wishes to force a cache to validate every
+ request, it can assign an explicit expiration time in the past to
+ indicate that the response is already stale. Compliant caches will
+ validate the cached response before reusing it for subsequent
+ requests.
+
+ Since origin servers do not always provide explicit expiration times,
+ HTTP caches MAY assign heuristic expiration times when explicit times
+ are not specified, employing algorithms that use other header values
+ (such as the Last-Modified time) to estimate a plausible expiration
+ time. The HTTP/1.1 specification does not provide specific
+ algorithms, but does impose worst-case constraints on their results.
+
+ The calculation to determine if a response is fresh is:
+
+ response_is_fresh = (freshness_lifetime > current_age)
+
+ The freshness_lifetime is defined in Section 2.3.1; the current_age
+ is defined in Section 2.3.2.
+
+ Additionally, clients might need to influence freshness calculation.
+ They can do this using several request cache directives, with the
+ effect of either increasing or loosening constraints on freshness.
+ See Section 3.2.1.
+
+ [[ISSUE-no-req-for-directives: there are not requirements directly
+ applying to cache-request-directives and freshness.]]
+
+ Note that freshness applies only to cache operation; it cannot be
+ used to force a user agent to refresh its display or reload a
+ resource. See Section 4 for an explanation of the difference between
+ caches and history mechanisms.
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 10]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+2.3.1. Calculating Freshness Lifetime
+
+ A cache can calculate the freshness lifetime (denoted as
+ freshness_lifetime) of a response by using the first match of:
+
+ o If the cache is shared and the s-maxage response cache directive
+ (Section 3.2.2) is present, use its value, or
+
+ o If the max-age response cache directive (Section 3.2.2) is
+ present, use its value, or
+
+ o If the Expires response header (Section 3.3) is present, use its
+ value minus the value of the Date response header, or
+
+ o Otherwise, no explicit expiration time is present in the response.
+ A heuristic freshness lifetime might be applicable; see
+ Section 2.3.1.1.
+
+ Note that this calculation is not vulnerable to clock skew, since all
+ of the information comes from the origin server.
+
+2.3.1.1. Calculating Heuristic Freshness
+
+ If no explicit expiration time is present in a stored response that
+ has a status code whose definition allows heuristic freshness to be
+ used (including the following in Section 8 of [Part2]: 200, 203, 206,
+ 300, 301 and 410), a heuristic expiration time MAY be calculated.
+ Heuristics MUST NOT be used for response status codes that do not
+ explicitly allow it.
+
+ When a heuristic is used to calculate freshness lifetime, the cache
+ SHOULD attach a Warning header with a 113 warn-code to the response
+ if its current_age is more than 24 hours and such a warning is not
+ already present.
+
+ Also, if the response has a Last-Modified header (Section 6.6 of
+ [Part4]), the heuristic expiration value SHOULD be no more than some
+ fraction of the interval since that time. A typical setting of this
+ fraction might be 10%.
+
+ Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
+ not calculate heuristic freshness for URLs with query components
+ (i.e., those containing '?'). In practice, this has not been
+ widely implemented. Therefore, servers are encouraged to send
+ explicit directives (e.g., Cache-Control: no-cache) if they wish
+ to preclude caching.
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 11]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+2.3.2. Calculating Age
+
+ HTTP/1.1 uses the Age response-header to convey the estimated age of
+ the response message when obtained from a cache. The Age field value
+ is the cache's estimate of the amount of time since the response was
+ generated or validated by the origin server. In essence, the Age
+ value is the sum of the time that the response has been resident in
+ each of the caches along the path from the origin server, plus the
+ amount of time it has been in transit along network paths.
+
+ The following data is used for the age calculation:
+
+ age_value
+
+ The term "age_value" denotes the value of the Age header
+ (Section 3.1), in a form appropriate for arithmetic operation; or
+ 0, if not available.
+
+ date_value
+
+ HTTP/1.1 requires origin servers to send a Date header, if
+ possible, with every response, giving the time at which the
+ response was generated. The term "date_value" denotes the value
+ of the Date header, in a form appropriate for arithmetic
+ operations. See Section 9.3 of [Part1] for the definition of the
+ Date header, and for requirements regarding responses without a
+ Date response header.
+
+ now
+
+ The term "now" means "the current value of the clock at the host
+ performing the calculation". Hosts that use HTTP, but especially
+ hosts running origin servers and caches, SHOULD use NTP
+ ([RFC1305]) or some similar protocol to synchronize their clocks
+ to a globally accurate time standard.
+
+ request_time
+
+ The current value of the clock at the host at the time the request
+ resulting in the stored response was made.
+
+ response_time
+
+ The current value of the clock at the host at the time the
+ response was received.
+
+ A response's age can be calculated in two entirely independent ways:
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 12]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ 1. the "apparent_age": response_time minus date_value, if the local
+ clock is reasonably well synchronized to the origin server's
+ clock. If the result is negative, the result is replaced by
+ zero.
+
+ 2. the "corrected_age_value", if all of the caches along the
+ response path implement HTTP/1.1; note this value MUST be
+ interpreted relative to the time the request was initiated, not
+ the time that the response was received.
+
+
+ apparent_age = max(0, response_time - date_value);
+
+ response_delay = response_time - request_time;
+ corrected_age_value = age_value + response_delay;
+
+ These are combined as
+
+ corrected_initial_age = max(apparent_age, corrected_age_value);
+
+ The current_age of a stored response can then be calculated by adding
+ the amount of time (in seconds) since the stored response was last
+ validated by the origin server to the corrected_initial_age.
+
+ resident_time = now - response_time;
+ current_age = corrected_initial_age + resident_time;
+
+2.3.3. Serving Stale Responses
+
+ A "stale" response is one that either has explicit expiry information
+ or is allowed to have heuristic expiry calculated, but is not fresh
+ according to the calculations in Section 2.3.
+
+ Caches MUST NOT return a stale response if it is prohibited by an
+ explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
+ cache directive, a "must-revalidate" cache-response-directive, or an
+ applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
+ see Section 3.2.2).
+
+ Caches SHOULD NOT return stale responses unless they are disconnected
+ (i.e., it cannot contact the origin server or otherwise find a
+ forward path) or otherwise explicitly allowed (e.g., the max-stale
+ request directive; see Section 3.2.1).
+
+ Stale responses SHOULD have a Warning header with the 110 warn-code
+ (see Section 3.6). Likewise, the 112 warn-code SHOULD be sent on
+ stale responses if the cache is disconnected.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 13]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ If a cache receives a first-hand response (either an entire response,
+ or a 304 (Not Modified) response) that it would normally forward to
+ the requesting client, and the received response is no longer fresh,
+ the cache SHOULD forward it to the requesting client without adding a
+ new Warning (but without removing any existing Warning headers). A
+ cache SHOULD NOT attempt to validate a response simply because that
+ response became stale in transit.
+
+2.4. Validation Model
+
+ When a cache has one or more stored responses for a requested URI,
+ but cannot serve any of them (e.g., because they are not fresh, or
+ one cannot be selected; see Section 2.7), it can use the conditional
+ request mechanism [Part4] in the forwarded request to give the origin
+ server an opportunity to both select a valid stored response to be
+ used, and to update it. This process is known as "validating" or
+ "revalidating" the stored response.
+
+ When sending such a conditional request, the cache SHOULD add an If-
+ Modified-Since header whose value is that of the Last-Modified header
+ from the selected (see Section 2.7) stored response, if available.
+
+ Additionally, the cache SHOULD add an If-None-Match header whose
+ value is that of the ETag header(s) from all responses stored for the
+ requested URI, if present. However, if any of the stored responses
+ contains only partial content, its entity-tag SHOULD NOT be included
+ in the If-None-Match header field unless the request is for a range
+ that would be fully satisfied by that stored response.
+
+ A 304 (Not Modified) response status code indicates that the stored
+ response can be updated and reused; see Section 2.8.
+
+ A full response (i.e., one with a response body) indicates that none
+ of the stored responses nominated in the conditional request is
+ suitable. Instead, the full response SHOULD be used to satisfy the
+ request and MAY replace the stored response.
+
+ If a cache receives a 5xx response while attempting to validate a
+ response, 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 return a previously stored response (see Section 2.3.3).
+
+2.5. Request Methods that Invalidate
+
+ Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
+ for changing state on the origin server, intervening caches can use
+ them to keep their contents up-to-date.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 14]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ The following HTTP methods MUST cause a cache to invalidate the
+ effective Request URI (Section 4.3 of [Part1]) as well as the URI(s)
+ in the Location and Content-Location headers (if present):
+
+ o PUT
+
+ o DELETE
+
+ o POST
+
+ An invalidation based on a URI from a Location or Content-Location
+ header MUST NOT be performed if the host part of that URI differs
+ from the host part in the effective request URI (Section 4.3 of
+ [Part1]). This helps prevent denial of service attacks.
+
+ A cache that passes through requests for methods it does not
+ understand SHOULD invalidate the effective request URI (Section 4.3
+ of [Part1]).
+
+ Here, "invalidate" means that the cache will either remove all stored
+ responses related to the effective request URI, or will mark these as
+ "invalid" and in need of a mandatory validation before they can be
+ returned in response to a subsequent request.
+
+ Note that this does not guarantee that all appropriate responses are
+ invalidated. For example, the request that caused the change at the
+ origin server might not have gone through the cache where a response
+ is stored.
+
+2.6. Shared Caching of Authenticated Responses
+
+ Shared caches MUST NOT use a cached response to a request with an
+ Authorization header (Section 3.1 of [Part7]) to satisfy any
+ subsequent request unless a cache directive that allows such
+ responses to be stored is present in the response.
+
+ In this specification, the following Cache-Control response
+ directives (Section 3.2.2) have such an effect: must-revalidate,
+ public, s-maxage.
+
+ Note that cached responses that contain the "must-revalidate" and/or
+ "s-maxage" response directives are not allowed to be served stale
+ (Section 2.3.3) by shared caches. In particular, a response with
+ either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
+ satisfy a subsequent request without revalidating it on the origin
+ server.
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 15]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+2.7. Caching Negotiated Responses
+
+ When a cache receives a request that can be satisfied by a stored
+ response that has a Vary header field (Section 3.5), it MUST NOT use
+ that response unless all of the selecting request-headers nominated
+ by the Vary header match in both the original request (i.e., that
+ associated with the stored response), and the presented request.
+
+ The selecting request-headers from two requests are defined to match
+ if and only if those in the first request can be transformed to those
+ in the second request by applying any of the following:
+
+ o adding or removing whitespace, where allowed in the header's
+ syntax
+
+ o combining multiple message-header fields with the same field name
+ (see Section 3.2 of [Part1])
+
+ o normalizing both header values in a way that is known to have
+ identical semantics, according to the header's specification
+ (e.g., re-ordering field values when order is not significant;
+ case-normalization, where values are defined to be case-
+ insensitive)
+
+ If (after any normalization that might take place) a header field is
+ absent from a request, it can only match another request if it is
+ also absent there.
+
+ A Vary header field-value of "*" always fails to match, and
+ subsequent requests to that resource can only be properly interpreted
+ by the origin server.
+
+ The stored response with matching selecting request-headers is known
+ as the selected response.
+
+ If no selected response is available, the cache MAY forward the
+ presented request to the origin server in a conditional request; see
+ Section 2.4.
+
+2.8. Combining Responses
+
+ When a cache receives a 304 (Not Modified) response or a 206 (Partial
+ Content) response (in this section, the "new" response"), it needs to
+ created an updated response by combining the stored response with the
+ new one, so that the updated response can be used to satisfy the
+ request, and potentially update the cached response.
+
+ If the new response contains an ETag, it identifies the stored
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 16]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ response to use. [[TODO-mention-CL: might need language about
+ Content-Location here]][[TODO-select-for-combine: Shouldn't this be
+ the selected response?]]
+
+ If the new response's status code is 206 (partial content), both the
+ stored and new responses MUST have validators, and those validators
+ MUST match using the strong comparison function (see Section 4 of
+ [Part4]). Otherwise, the responses MUST NOT be combined.
+
+ The stored response headers are used as those of the updated
+ response, except that
+
+ o any stored Warning headers with warn-code 1xx (see Section 3.6)
+ MUST be deleted.
+
+ o any stored Warning headers with warn-code 2xx MUST be retained.
+
+ o any other headers provided in the new response MUST replace all
+ instances of the corresponding headers from the stored response.
+
+ The updated response headers MUST be used to replace those of the
+ stored response in cache (unless the stored response is removed from
+ cache). In the case of a 206 response, the combined representation
+ MAY be stored.
+
+3. Header Field Definitions
+
+ This section defines the syntax and semantics of HTTP/1.1 header
+ fields related to caching.
+
+3.1. Age
+
+ The "Age" response-header field conveys the sender's estimate of the
+ amount of time since the response was generated or successfully
+ validated at the origin server. Age values are calculated as
+ specified in Section 2.3.2.
+
+ Age = "Age" ":" OWS Age-v
+ Age-v = delta-seconds
+
+ Age field-values are non-negative integers, representing time in
+ seconds.
+
+ delta-seconds = 1*DIGIT
+
+ If a cache receives a value larger than the largest positive integer
+ it can represent, or if any of its age calculations overflows, it
+ MUST transmit an Age header with a field-value of 2147483648 (2^31).
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 17]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Caches SHOULD use an arithmetic type of at least 31 bits of range.
+
+ The presence of an Age header field in a response implies that a
+ response is not first-hand. However, the converse is not true, since
+ HTTP/1.0 caches might not implement the Age header field.
+
+3.2. Cache-Control
+
+ The "Cache-Control" general-header field is used to specify
+ directives for caches along the request/response chain. Such cache
+ directives are unidirectional in that the presence of a directive in
+ a request does not imply that the same directive is to be given in
+ the response.
+
+ HTTP/1.1 caches MUST obey the requirements of the Cache-Control
+ directives defined in this section. See Section 3.2.3 for
+ information about how Cache-Control directives defined elsewhere are
+ handled.
+
+ Note: HTTP/1.0 caches might not implement Cache-Control and might
+ only implement Pragma: no-cache (see Section 3.4).
+
+ Cache directives MUST be passed through by a proxy or gateway
+ application, regardless of their significance to that application,
+ since the directives might be applicable to all recipients along the
+ request/response chain. It is not possible to target a directive to
+ a specific cache.
+
+ Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
+ Cache-Control-v = 1#cache-directive
+
+ cache-directive = cache-request-directive
+ / cache-response-directive
+
+ cache-extension = token [ "=" ( token / quoted-string ) ]
+
+3.2.1. Request Cache-Control Directives
+
+ cache-request-directive =
+ "no-cache"
+ / "no-store"
+ / "max-age" "=" delta-seconds
+ / "max-stale" [ "=" delta-seconds ]
+ / "min-fresh" "=" delta-seconds
+ / "no-transform"
+ / "only-if-cached"
+ / cache-extension
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 18]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ no-cache
+
+ The no-cache request directive indicates that a stored response
+ MUST NOT be used to satisfy the request without successful
+ validation on the origin server.
+
+ no-store
+
+ The no-store request directive indicates that a cache MUST NOT
+ store any part of either this request or any response to it. This
+ directive applies to both non-shared 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 remove the information from volatile
+ storage as promptly as possible after forwarding it.
+
+ This directive is NOT a reliable or sufficient mechanism for
+ ensuring privacy. In particular, malicious or compromised caches
+ might not recognize or obey this directive, and communications
+ networks might be vulnerable to eavesdropping.
+
+ max-age
+
+ The max-age request directive indicates that the client is willing
+ to accept a response whose age is no greater than the specified
+ time in seconds. Unless the max-stale request directive is also
+ present, the client is not willing to accept a stale response.
+
+ max-stale
+
+ The max-stale request directive 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 the client is willing to accept a
+ stale response of any age.
+
+ min-fresh
+
+ The min-fresh request directive indicates that the client is
+ willing to accept a response whose freshness lifetime is no less
+ than its current age plus the specified time in seconds. That is,
+ the client wants a response that will still be fresh for at least
+ the specified number of seconds.
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 19]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ no-transform
+
+ The no-transform request directive indicates that an intermediate
+ cache or proxy MUST NOT change the Content-Encoding, Content-Range
+ or Content-Type request headers, nor the request representation.
+
+ only-if-cached
+
+ The only-if-cached request directive indicates that the client
+ only wishes to return a stored response. If it receives this
+ directive, a cache SHOULD either respond using a stored response
+ that is consistent with the other constraints of the request, or
+ respond with a 504 (Gateway Timeout) status code. If a group of
+ caches is being operated as a unified system with good internal
+ connectivity, such a request MAY be forwarded within that group of
+ caches.
+
+3.2.2. Response Cache-Control Directives
+
+ cache-response-directive =
+ "public"
+ / "private" [ "=" DQUOTE 1#field-name DQUOTE ]
+ / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]
+ / "no-store"
+ / "no-transform"
+ / "must-revalidate"
+ / "proxy-revalidate"
+ / "max-age" "=" delta-seconds
+ / "s-maxage" "=" delta-seconds
+ / cache-extension
+
+ public
+
+ The public response directive indicates that the response MAY be
+ cached, even if it would normally be non-cacheable or cacheable
+ only within a non-shared cache. (See also Authorization, Section
+ 3.1 of [Part7], for additional details.)
+
+ private
+
+ The private response directive indicates that the response message
+ is intended for a single user and MUST NOT be stored by a shared
+ cache. A private (non-shared) cache MAY store the response.
+
+ If the private response directive specifies one or more field-
+ names, this requirement is limited to the field-values associated
+ with the listed response headers. That is, the specified field-
+ names(s) MUST NOT be stored by a shared cache, whereas the
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 20]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ remainder of the response message MAY be.
+
+ Note: This usage of the word private only controls where the
+ response can be stored; it cannot ensure the privacy of the
+ message content. Also, private response directives with field-
+ names are often handled by implementations as if an unqualified
+ private directive was received; i.e., the special handling for the
+ qualified form is not widely implemented.
+
+ no-cache
+
+ The no-cache response directive indicates that the response MUST
+ NOT be used to satisfy a subsequent request without successful
+ validation on the origin server. This allows an origin server to
+ prevent a cache from using it to satisfy a request without
+ contacting it, even by caches that have been configured to return
+ stale responses.
+
+ If the no-cache response directive specifies one or more field-
+ names, this requirement is limited to the field-values associated
+ with the listed response headers. That is, the specified field-
+ name(s) MUST NOT be sent in the response to a subsequent request
+ without successful validation on the origin server. This allows
+ an origin server to prevent the re-use of certain header fields in
+ a response, while still allowing caching of the rest of the
+ response.
+
+ Note: Most HTTP/1.0 caches will not recognize or obey this
+ directive. Also, no-cache response directives with field-names
+ are often handled by implementations as if an unqualified no-cache
+ directive was received; i.e., the special handling for the
+ qualified form is not widely implemented.
+
+ no-store
+
+ The no-store response directive indicates that a cache MUST NOT
+ store any part of either the immediate request or response. This
+ directive applies to both non-shared 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 remove the information from volatile
+ storage as promptly as possible after forwarding it.
+
+ This directive is NOT a reliable or sufficient mechanism for
+ ensuring privacy. In particular, malicious or compromised caches
+ might not recognize or obey this directive, and communications
+ networks might be vulnerable to eavesdropping.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 21]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ must-revalidate
+
+ The must-revalidate response directive indicates that once it has
+ become stale, the response MUST NOT be used to satisfy subsequent
+ requests without successful validation on the origin server.
+
+ The must-revalidate directive is necessary to support reliable
+ operation for certain protocol features. In all circumstances an
+ HTTP/1.1 cache MUST obey the must-revalidate directive; in
+ particular, if the cache cannot reach the origin server for any
+ reason, it MUST generate a 504 (Gateway Timeout) response.
+
+ Servers SHOULD send the must-revalidate directive if and only if
+ failure to validate a request on the representation could result
+ in incorrect operation, such as a silently unexecuted financial
+ transaction.
+
+ proxy-revalidate
+
+ The proxy-revalidate response directive has the same meaning as
+ the must-revalidate response directive, except that it does not
+ apply to non-shared caches.
+
+ max-age
+
+ The max-age response directive indicates that response is to be
+ considered stale after its age is greater than the specified
+ number of seconds.
+
+ s-maxage
+
+ The s-maxage response directive indicates that, in shared caches,
+ the maximum age specified by this directive overrides the maximum
+ age specified by either the max-age directive or the Expires
+ header. The s-maxage directive also implies the semantics of the
+ proxy-revalidate response directive.
+
+ no-transform
+
+ The no-transform response directive indicates that an intermediate
+ cache or proxy MUST NOT change the Content-Encoding, Content-Range
+ or Content-Type response headers, nor the response representation.
+
+3.2.3. 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 value.
+ Informational extensions (those that do not require a change in cache
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 22]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ behavior) can 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 that 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.
+
+ This extension mechanism depends on an HTTP cache obeying all of the
+ cache-control directives defined for its native HTTP-version, obeying
+ certain extensions, and ignoring all directives that it does not
+ understand.
+
+ For example, consider a hypothetical new response directive called
+ "community" that 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 that 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) could 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
+ cacheability) such that the cache behavior will remain minimally
+ correct even if the cache does not understand the extension(s).
+
+ The HTTP Cache Directive Registry defines the name space for the
+ cache directives.
+
+ Registrations MUST include the following fields:
+
+ o Cache Directive Name
+
+ o Pointer to specification text
+
+ Values to be added to this name space are subject to IETF review
+ ([RFC5226], Section 4.1).
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 23]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ The registry itself is maintained at
+ <http://www.iana.org/assignments/http-cache-directives>.
+
+3.3. Expires
+
+ The "Expires" header field gives the date/time after which the
+ response is considered stale. See Section 2.3 for further discussion
+ of the freshness model.
+
+ The presence of an Expires field does not imply that the original
+ resource will change or cease to exist at, before, or after that
+ time.
+
+ The field-value is an absolute date and time as defined by HTTP-date
+ in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format.
+
+ Expires = "Expires" ":" OWS Expires-v
+ Expires-v = HTTP-date
+
+ For example
+
+ Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+ Note: If a response includes a Cache-Control field with the max-
+ age directive (see Section 3.2.2), that directive overrides the
+ Expires field. Likewise, the s-maxage directive overrides Expires
+ in shared caches.
+
+ HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in
+ the future.
+
+ HTTP/1.1 clients and caches MUST treat other invalid date formats,
+ especially including the value "0", as in the past (i.e., "already
+ expired").
+
+3.4. Pragma
+
+ The "Pragma" general-header field is used to include implementation-
+ specific directives that might apply to any recipient along the
+ request/response chain. All pragma directives specify optional
+ behavior from the viewpoint of the protocol; however, some systems
+ MAY require that behavior be consistent with the directives.
+
+ Pragma = "Pragma" ":" OWS Pragma-v
+ Pragma-v = 1#pragma-directive
+ pragma-directive = "no-cache" / extension-pragma
+ extension-pragma = token [ "=" ( token / quoted-string ) ]
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 24]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ When the no-cache directive is present in a request message, an
+ application SHOULD forward the request toward the origin server even
+ if it has a cached copy of what is being requested. This pragma
+ directive has the same semantics as the no-cache response directive
+ (see Section 3.2.2) and is defined here for backward compatibility
+ with HTTP/1.0. Clients SHOULD include both header fields when a no-
+ cache request is sent to a server not known to be HTTP/1.1 compliant.
+ HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
+ sent "Cache-Control: no-cache".
+
+ Note: Because the meaning of "Pragma: no-cache" as a response-
+ header field is not actually specified, it does not provide a
+ reliable replacement for "Cache-Control: no-cache" in a response.
+
+ This mechanism is deprecated; no new Pragma directives will be
+ defined in HTTP.
+
+3.5. Vary
+
+ The "Vary" response-header field conveys the set of request-header
+ fields that were used to select the representation.
+
+ Caches use this information, in part, to determine whether a stored
+ response can be used to satisfy a given request; see Section 2.7.
+ determines, while the response is fresh, whether a cache is permitted
+ to use the response to reply to a subsequent request without
+ validation; see Section 2.7.
+
+ In uncacheable or stale responses, the Vary field value advises the
+ user agent about the criteria that were used to select the
+ representation.
+
+ Vary = "Vary" ":" OWS Vary-v
+ Vary-v = "*" / 1#field-name
+
+ The set of header fields named by the Vary field value is known as
+ the selecting request-headers.
+
+ Servers SHOULD include a Vary header field with any cacheable
+ response that is subject to server-driven negotiation. Doing so
+ allows a cache to properly interpret future requests on that resource
+ and informs the user agent about the presence of negotiation on that
+ resource. A server MAY include a Vary header field with a non-
+ cacheable response that is subject to server-driven negotiation,
+ since this might provide the user agent with useful information about
+ the dimensions over which the response varies at the time of the
+ response.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 25]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ A Vary field value of "*" signals that unspecified parameters not
+ limited to the request-headers (e.g., the network address of the
+ client), play a role in the selection of the response representation;
+ therefore, a cache cannot determine whether this response is
+ appropriate. The "*" value MUST NOT be generated by a proxy server.
+
+ The field-names given are not limited to the set of standard request-
+ header fields defined by this specification. Field names are case-
+ insensitive.
+
+3.6. Warning
+
+ The "Warning" general-header field is used to carry additional
+ information about the status or transformation of a message that
+ might not be reflected in the message. This information is typically
+ used to warn about possible incorrectness introduced by caching
+ operations or transformations applied to the payload of the message.
+
+ Warnings can be used for other purposes, both cache-related and
+ otherwise. The use of a warning, rather than an error status code,
+ distinguishes these responses from true failures.
+
+ Warning headers can in general be applied to any message, however
+ some warn-codes are specific to caches and can only be applied to
+ response messages.
+
+ Warning = "Warning" ":" OWS Warning-v
+ Warning-v = 1#warning-value
+
+ warning-value = warn-code SP warn-agent SP warn-text
+ [SP warn-date]
+
+ warn-code = 3DIGIT
+ warn-agent = ( uri-host [ ":" port ] ) / pseudonym
+ ; the name or pseudonym of the server adding
+ ; the Warning header, for use in debugging
+ warn-text = quoted-string
+ warn-date = DQUOTE HTTP-date DQUOTE
+
+ Multiple warnings can be attached to a response (either by the origin
+ server or by a cache), including multiple warnings with the same code
+ number, only differing in warn-text.
+
+ When this occurs, the user agent SHOULD inform the user of as many of
+ them as possible, in the order that they appear in the response.
+
+ Systems that generate multiple Warning headers SHOULD order them with
+ this user agent behavior in mind. New Warning headers SHOULD be
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 26]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ added after any existing Warning headers.
+
+ Warnings are assigned three digit warn-codes. The first digit
+ indicates whether the Warning is required to be deleted from a stored
+ response after validation:
+
+ o 1xx Warnings describe the freshness or validation status of the
+ response, and so MUST be deleted by caches after validation. They
+ can only be generated by a cache when validating a cached entry,
+ and MUST NOT be generated in any other situation.
+
+ o 2xx Warnings describe some aspect of the representation that is
+ not rectified by a validation (for example, a lossy compression of
+ the representation) and MUST NOT be deleted by caches after
+ validation, unless a full response is returned, in which case they
+ MUST be.
+
+ If an implementation sends a message with one or more Warning headers
+ to a receiver whose version is HTTP/1.0 or lower, then the sender
+ MUST include in each warning-value a warn-date that matches the Date
+ header in the message.
+
+ If an implementation receives a message with a warning-value that
+ includes a warn-date, and that warn-date is different from the Date
+ value in the response, then that warning-value MUST be deleted from
+ the message before storing, forwarding, or using it. (preventing the
+ consequences of naive caching of Warning header fields.) If all of
+ the warning-values are deleted for this reason, the Warning header
+ MUST be deleted as well.
+
+ The following warn-codes are defined by this specification, each with
+ a recommended warn-text in English, and a description of its meaning.
+
+ 110 Response is stale
+
+ SHOULD be included whenever the returned response is stale.
+
+ 111 Revalidation failed
+
+ SHOULD be included if a cache returns a stale response because an
+ attempt to validate the response failed, due to an inability to
+ reach the server.
+
+ 112 Disconnected operation
+
+ SHOULD be included if the cache is intentionally disconnected from
+ the rest of the network for a period of time.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 27]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ 113 Heuristic expiration
+
+ SHOULD be included if the cache heuristically chose a freshness
+ lifetime greater than 24 hours and the response's age is greater
+ than 24 hours.
+
+ 199 Miscellaneous warning
+
+ The warning text can include arbitrary information to be presented
+ to a human user, or logged. A system receiving this warning MUST
+ NOT take any automated action, besides presenting the warning to
+ the user.
+
+ 214 Transformation applied
+
+ MUST be added by an intermediate proxy if it applies any
+ transformation to the representation, such as changing the
+ content-coding, media-type, or modifying the representation data,
+ unless this Warning code already appears in the response.
+
+ 299 Miscellaneous persistent warning
+
+ The warning text can include arbitrary information to be presented
+ to a human user, or logged. A system receiving this warning MUST
+ NOT take any automated action.
+
+4. History Lists
+
+ User agents often have history mechanisms, such as "Back" buttons and
+ history lists, that can be used to redisplay a representation
+ retrieved earlier in a session.
+
+ The freshness model (Section 2.3) does not necessarily apply to
+ history mechanisms. I.e., a history mechanism can display a previous
+ representation even if it has expired.
+
+ This does not prohibit the history mechanism from telling the user
+ that a view might be stale, or from honoring cache directives (e.g.,
+ Cache-Control: no-store).
+
+5. IANA Considerations
+
+5.1. Cache Directive Registry
+
+ The registration procedure for HTTP Cache Directives is defined by
+ Section 3.2.3 of this document.
+
+ The HTTP Cache Directive Registry shall be created at
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 28]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ <http://www.iana.org/assignments/http-cache-directives> and be
+ populated with the registrations below:
+
+ +------------------------+------------------------------+
+ | Cache Directive | Reference |
+ +------------------------+------------------------------+
+ | max-age | Section 3.2.1, Section 3.2.2 |
+ | max-stale | Section 3.2.1 |
+ | min-fresh | Section 3.2.1 |
+ | must-revalidate | Section 3.2.2 |
+ | no-cache | Section 3.2.1, Section 3.2.2 |
+ | no-store | Section 3.2.1, Section 3.2.2 |
+ | no-transform | Section 3.2.1, Section 3.2.2 |
+ | only-if-cached | Section 3.2.1 |
+ | private | Section 3.2.2 |
+ | proxy-revalidate | Section 3.2.2 |
+ | public | Section 3.2.2 |
+ | s-maxage | Section 3.2.2 |
+ | stale-if-error | [RFC5861], Section 4 |
+ | stale-while-revalidate | [RFC5861], Section 3 |
+ +------------------------+------------------------------+
+
+5.2. Header Field Registration
+
+ The Message Header Field Registry located at <http://www.iana.org/
+ assignments/message-headers/message-header-index.html> shall be
+ updated with the permanent registrations below (see [RFC3864]):
+
+ +-------------------+----------+----------+-------------+
+ | Header Field Name | Protocol | Status | Reference |
+ +-------------------+----------+----------+-------------+
+ | Age | http | standard | Section 3.1 |
+ | Cache-Control | http | standard | Section 3.2 |
+ | Expires | http | standard | Section 3.3 |
+ | Pragma | http | standard | Section 3.4 |
+ | Vary | http | standard | Section 3.5 |
+ | Warning | http | standard | Section 3.6 |
+ +-------------------+----------+----------+-------------+
+
+ The change controller is: "IETF (iesg@ietf.org) - Internet
+ Engineering Task Force".
+
+6. Security Considerations
+
+ Caches expose additional potential vulnerabilities, since the
+ contents of the cache represent an attractive target for malicious
+ exploitation. Because cache contents persist after an HTTP request
+ is complete, an attack on the cache can reveal information long after
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 29]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ a user believes that the information has been removed from the
+ network. Therefore, cache contents need to be protected as sensitive
+ information.
+
+7. Acknowledgments
+
+ Much of the content and presentation of the caching design is due to
+ suggestions and comments from individuals including: Shel Kaphan,
+ Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
+
+8. References
+
+8.1. Normative References
+
+ [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
+ and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
+ and Message Parsing", draft-ietf-httpbis-p1-messaging-11
+ (work in progress), August 2010.
+
+ [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
+ and J. Reschke, Ed., "HTTP/1.1, part 2: Message
+ Semantics", draft-ietf-httpbis-p2-semantics-11 (work in
+ progress), August 2010.
+
+ [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
+ and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
+ Requests", draft-ietf-httpbis-p4-conditional-11 (work in
+ progress), August 2010.
+
+ [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
+ and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
+ Partial Responses", draft-ietf-httpbis-p5-range-11 (work
+ in progress), August 2010.
+
+ [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
+ and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
+ draft-ietf-httpbis-p7-auth-11 (work in progress),
+ August 2010.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 30]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+8.2. Informative References
+
+ [RFC1305] Mills, D., "Network Time Protocol (Version 3)
+ Specification, Implementation", RFC 1305, March 1992.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90, RFC 3864,
+ September 2004.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
+ Content", RFC 5861, April 2010.
+
+Appendix A. Changes from RFC 2616
+
+ Make the specified age calculation algorithm less conservative.
+ (Section 2.3.2)
+
+ Remove requirement to consider Content-Location in successful
+ responses in order to determine the appropriate response to use.
+ (Section 2.4)
+
+ Clarify denial of service attack avoidance requirement.
+ (Section 2.5)
+
+ Do not mention RFC 2047 encoding and multiple languages in Warning
+ headers anymore, as these aspects never were implemented.
+ (Section 3.6)
+
+Appendix B. Collected ABNF
+
+ Age = "Age:" OWS Age-v
+ Age-v = delta-seconds
+
+ Cache-Control = "Cache-Control:" OWS Cache-Control-v
+ Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS
+ cache-directive ] )
+
+ Expires = "Expires:" OWS Expires-v
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 31]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Expires-v = HTTP-date
+
+ HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
+
+ OWS = <OWS, defined in [Part1], Section 1.2.2>
+
+ Pragma = "Pragma:" OWS Pragma-v
+ Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS
+ pragma-directive ] )
+
+ Vary = "Vary:" OWS Vary-v
+ Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name
+ ] ) )
+
+ Warning = "Warning:" OWS Warning-v
+ Warning-v = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value
+ ] )
+
+ cache-directive = cache-request-directive / cache-response-directive
+ cache-extension = token [ "=" ( token / quoted-string ) ]
+ cache-request-directive = "no-cache" / "no-store" / ( "max-age="
+ delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / (
+ "min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" /
+ cache-extension
+ cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( ","
+ OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (
+ "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS
+ field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /
+ "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds
+ ) / ( "s-maxage=" delta-seconds ) / cache-extension
+
+ delta-seconds = 1*DIGIT
+
+ extension-pragma = token [ "=" ( token / quoted-string ) ]
+
+ field-name = <field-name, defined in [Part1], Section 3.2>
+
+ port = <port, defined in [Part1], Section 2.6>
+ pragma-directive = "no-cache" / extension-pragma
+ pseudonym = <pseudonym, defined in [Part1], Section 9.9>
+
+ quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
+
+ token = <token, defined in [Part1], Section 1.2.2>
+
+ uri-host = <uri-host, defined in [Part1], Section 2.6>
+
+ warn-agent = ( uri-host [ ":" port ] ) / pseudonym
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 32]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ warn-code = 3DIGIT
+ warn-date = DQUOTE HTTP-date DQUOTE
+ warn-text = quoted-string
+ warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
+ ]
+
+ ABNF diagnostics:
+
+ ; Age defined but not used
+ ; Cache-Control defined but not used
+ ; Expires defined but not used
+ ; Pragma defined but not used
+ ; Vary defined but not used
+ ; Warning defined but not used
+
+Appendix C. Change Log (to be removed by RFC Editor before publication)
+
+C.1. Since RFC2616
+
+ Extracted relevant partitions from [RFC2616].
+
+C.2. Since draft-ietf-httpbis-p6-cache-00
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer"
+ (<http://purl.org/NET/http-errata#trailer-hop>)
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/12>: "Invalidation
+ after Update or Delete"
+ (<http://purl.org/NET/http-errata#invalidupd>)
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
+ Informative references"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
+ typo"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/49>: "Connection
+ header text"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
+ references"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
+ Reference"
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 33]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
+ to-date references"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in
+ 13.2.2"
+
+ Other changes:
+
+ o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress
+ on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
+
+C.3. Since draft-ietf-httpbis-p6-cache-01
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
+ used"
+
+ Other changes:
+
+ o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work
+ in progress on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
+
+ o Add explicit references to BNF syntax and rules imported from
+ other parts of the specification.
+
+C.4. Since draft-ietf-httpbis-p6-cache-02
+
+ Ongoing work on IANA Message Header Registration
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
+
+ o Reference RFC 3984, and update header registrations for headers
+ defined in this document.
+
+C.5. Since draft-ietf-httpbis-p6-cache-03
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary header
+ classification"
+
+C.6. Since draft-ietf-httpbis-p6-cache-04
+
+ Ongoing work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Use "/" instead of "|" for alternatives.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 34]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
+ whitespace ("OWS") and required whitespace ("RWS").
+
+ o Rewrite ABNFs to spell out whitespace rules, factor out header
+ value format definitions.
+
+C.7. Since draft-ietf-httpbis-p6-cache-05
+
+ This is a total rewrite of this part of the specification.
+
+ Affected issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of
+ 1xx Warn-Codes"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
+ 13.5.1 and 13.5.2"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role of
+ Warning and Semantic Transparency in Caching"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and
+ Caching"
+
+ In addition: Final work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Add appendix containing collected and expanded ABNF, reorganize
+ ABNF introduction.
+
+C.8. Since draft-ietf-httpbis-p6-cache-06
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
+ numeric protocol elements"
+
+ Affected issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non-
+ existant headers
+
+C.9. Since draft-ietf-httpbis-p6-cache-07
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of
+ 1xx Warn-Codes"
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 35]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content-
+ Location on 304 responses"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and
+ no-cache CC directives with headers"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and
+ warn-text"
+
+C.10. Since draft-ietf-httpbis-p6-cache-08
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving
+ negotiated responses from cache: header-specific canonicalization"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC
+ directives on history lists"
+
+ Affected issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
+ and caching
+
+ Partly resolved issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
+ 13.5.1 and 13.5.2"
+
+C.11. Since draft-ietf-httpbis-p6-cache-09
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/29>: "Age
+ calculation"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/168>: "Clarify
+ differences between / requirements for request and response CC
+ directives"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/174>: "Caching
+ authenticated responses"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/208>: "IANA registry
+ for cache-control directives"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/211>: "Heuristic
+ caching of URLs with query components"
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 36]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Partly resolved issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
+ requested resource's URI"
+
+C.12. Since draft-ietf-httpbis-p6-cache-10
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
+ entity / representation / variant terminology"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
+ removing the 'changes from 2068' sections"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
+ heuristic caching for new status codes"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
+ heuristic caching for new status codes"
+
+ o Clean up TODOs and prose in "Combining Responses."
+
+Index
+
+ A
+ age 6
+ Age header 17
+
+ C
+ cache 5
+ Cache Directives
+ max-age 19, 22
+ max-stale 19
+ min-fresh 19
+ must-revalidate 22
+ no-cache 19, 21
+ no-store 19, 21
+ no-transform 20, 22
+ only-if-cached 20
+ private 20
+ proxy-revalidate 22
+ public 20
+ s-maxage 22
+ Cache-Control header 18
+ cacheable 5
+
+ E
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 37]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Expires header 24
+ explicit expiration time 5
+
+ F
+ first-hand 6
+ fresh 6
+ freshness lifetime 6
+
+ G
+ Grammar
+ Age 17
+ Age-v 17
+ Cache-Control 18
+ Cache-Control-v 18
+ cache-extension 18
+ cache-request-directive 18
+ cache-response-directive 20
+ delta-seconds 17
+ Expires 24
+ Expires-v 24
+ extension-pragma 24
+ Pragma 24
+ pragma-directive 24
+ Pragma-v 24
+ Vary 25
+ Vary-v 25
+ warn-agent 26
+ warn-code 26
+ warn-date 26
+ warn-text 26
+ Warning 26
+ Warning-v 26
+ warning-value 26
+
+ H
+ Headers
+ Age 17
+ Cache-Control 18
+ Expires 24
+ Pragma 24
+ Vary 25
+ Warning 26
+ heuristic expiration time 5
+
+ M
+ max-age
+ Cache Directive 19, 22
+ max-stale
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 38]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Cache Directive 19
+ min-fresh
+ Cache Directive 19
+ must-revalidate
+ Cache Directive 22
+
+ N
+ no-cache
+ Cache Directive 19, 21
+ no-store
+ Cache Directive 19, 21
+ no-transform
+ Cache Directive 20, 22
+
+ O
+ only-if-cached
+ Cache Directive 20
+
+ P
+ Pragma header 24
+ private
+ Cache Directive 20
+ proxy-revalidate
+ Cache Directive 22
+ public
+ Cache Directive 20
+
+ S
+ s-maxage
+ Cache Directive 22
+ stale 6
+
+ V
+ validator 6
+ Vary header 25
+
+ W
+ Warning header 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 39]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+Authors' Addresses
+
+ Roy T. Fielding (editor)
+ Day Software
+ 23 Corporate Plaza DR, Suite 280
+ Newport Beach, CA 92660
+ USA
+
+ Phone: +1-949-706-5300
+ Fax: +1-949-706-5305
+ EMail: fielding@gbiv.com
+ URI: http://roy.gbiv.com/
+
+
+ Jim Gettys
+ Alcatel-Lucent Bell Labs
+ 21 Oak Knoll Road
+ Carlisle, MA 01741
+ USA
+
+ EMail: jg@freedesktop.org
+ URI: http://gettys.wordpress.com/
+
+
+ Jeffrey C. Mogul
+ Hewlett-Packard Company
+ HP Labs, Large Scale Systems Group
+ 1501 Page Mill Road, MS 1177
+ Palo Alto, CA 94304
+ USA
+
+ EMail: JeffMogul@acm.org
+
+
+ Henrik Frystyk Nielsen
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ EMail: henrikn@microsoft.com
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 40]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Larry Masinter
+ Adobe Systems, Incorporated
+ 345 Park Ave
+ San Jose, CA 95110
+ USA
+
+ EMail: LMM@acm.org
+ URI: http://larry.masinter.net/
+
+
+ Paul J. Leach
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+
+ EMail: paulle@microsoft.com
+
+
+ Tim Berners-Lee
+ World Wide Web Consortium
+ MIT Computer Science and Artificial Intelligence Laboratory
+ The Stata Center, Building 32
+ 32 Vassar Street
+ Cambridge, MA 02139
+ USA
+
+ EMail: timbl@w3.org
+ URI: http://www.w3.org/People/Berners-Lee/
+
+
+ Yves Lafon (editor)
+ World Wide Web Consortium
+ W3C / ERCIM
+ 2004, rte des Lucioles
+ Sophia-Antipolis, AM 06902
+ France
+
+ EMail: ylafon@w3.org
+ URI: http://www.raubacapeu.net/people/yves/
+
+
+ Mark Nottingham (editor)
+
+ EMail: mnot@mnot.net
+ URI: http://www.mnot.net/
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 41]
+
+Internet-Draft HTTP/1.1, Part 6 August 2010
+
+
+ Julian F. Reschke (editor)
+ greenbytes GmbH
+ Hafenweg 16
+ Muenster, NW 48155
+ Germany
+
+ Phone: +49 251 2807760
+ Fax: +49 251 2807761
+ EMail: julian.reschke@greenbytes.de
+ URI: http://greenbytes.de/tech/webdav/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 42]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 15:11:16 +0000