draft-ietf-httpbis-p6-cache-24.txt   draft-ietf-httpbis-p6-cache-25.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) M. Nottingham, Ed. Obsoletes: 2616 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Akamai Intended status: Standards Track Akamai
Expires: March 29, 2014 J. Reschke, Ed. Expires: May 21, 2014 J. Reschke, Ed.
greenbytes greenbytes
September 25, 2013 November 17, 2013
Hypertext Transfer Protocol (HTTP/1.1): Caching Hypertext Transfer Protocol (HTTP/1.1): Caching
draft-ietf-httpbis-p6-cache-24 draft-ietf-httpbis-p6-cache-25
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. This document defines requirements on HTTP caches and the systems. This document defines requirements on HTTP caches and the
associated header fields that control cache behavior or indicate associated header fields that control cache behavior or indicate
cacheable response messages. cacheable response messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.5. The changes in this draft are summarized in Appendix D.1.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 29, 2014. This Internet-Draft will expire on May 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6
3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7
3.2. Storing Responses to Authenticated Requests . . . . . . . 7 3.2. Storing Responses to Authenticated Requests . . . . . . . 7
3.3. Combining Partial Content . . . . . . . . . . . . . . . . 7 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8
4. Constructing Responses from Caches . . . . . . . . . . . . . . 8 4. Constructing Responses from Caches . . . . . . . . . . . . . . 8
4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9
4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 14 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15 4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15
4.3.2. Handling a Received Validation Request . . . . . . . . 16 4.3.2. Handling a Received Validation Request . . . . . . . . 16
4.3.3. Handling a Validation Response . . . . . . . . . . . . 17 4.3.3. Handling a Validation Response . . . . . . . . . . . . 17
4.3.4. Freshening Stored Responses upon Validation . . . . . 18 4.3.4. Freshening Stored Responses upon Validation . . . . . 18
4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 18 4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 5.2.2. Response Cache-Control Directives . . . . . . . . . . 23
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 30 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 31
5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31
5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31
5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31
5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31
5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31
6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32
7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32
7.1.2. Considerations for New Cache Control Directives . . . 32 7.1.2. Considerations for New Cache Control Directives . . . 32
7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 33
7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33
7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33
7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33
7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 39 publication) . . . . . . . . . . . . . . . . . . . . 39
D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 40 D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40
D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 40 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
D.3. Since draft-ietf-httpbis-p6-cache-21 . . . . . . . . . . . 41
D.4. Since draft-ietf-httpbis-p6-cache-22 . . . . . . . . . . . 41
D.5. Since draft-ietf-httpbis-p6-cache-23 . . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
HTTP is typically used for distributed information systems, where HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. This performance can be improved by the use of response caches. This
document defines aspects of HTTP/1.1 related to caching and reusing document defines aspects of HTTP/1.1 related to caching and reusing
response messages. response messages.
An HTTP cache is a local store of response messages and the subsystem An HTTP cache is a local store of response messages and the subsystem
that controls storage, retrieval, and deletion of messages in it. A that controls storage, retrieval, and deletion of messages in it. A
skipping to change at page 5, line 12 skipping to change at page 5, line 12
documents. Appendix C shows the collected ABNF with the list rule documents. Appendix C shows the collected ABNF with the list rule
expanded. expanded.
1.2.1. Delta Seconds 1.2.1. Delta Seconds
The delta-seconds rule specifies a non-negative integer, representing The delta-seconds rule specifies a non-negative integer, representing
time in seconds. time in seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
If a cache receives a delta-seconds value larger than the largest A recipient parsing a delta-seconds value and converting it to binary
positive integer it can represent, or if any of its subsequent form ought to use an arithmetic type of at least 31 bits of non-
calculations overflows, the cache MUST consider the value to be negative integer range. If a cache receives a delta-seconds value
2147483648 (2^31). A recipient parsing a delta-seconds value MUST greater than the greatest integer it can represent, or if any of its
use an arithmetic type of at least 31 bits of range, and a sender subsequent calculations overflows, the cache MUST consider the value
MUST NOT generate delta-seconds with a value greater than 2147483648. to be either 2147483648 (2^31) or the greatest positive integer it
can conveniently represent.
Note: The value 2147483648 is here for historical reasons,
effectively represents infinity (over 68 years), and does not need
to be stored in binary form; an implementation could produce it as
a canned string if any overflow occurs, even if the calculations
are performed with an arithmetic type incapable of directly
representing that number. What matters here is that an overflow
be detected and not treated as a negative value in later
calculations.
2. Overview of Cache Operation 2. Overview of Cache Operation
Proper cache operation preserves the semantics of HTTP transfers Proper cache operation preserves the semantics of HTTP transfers
([Part2]) while eliminating the transfer of information already held ([Part2]) while eliminating the transfer of information already held
in the cache. Although caching is an entirely OPTIONAL feature of in the cache. Although caching is an entirely OPTIONAL feature of
HTTP, we assume that reusing the cached response is desirable and HTTP, we assume that reusing the cached response is desirable and
that such reuse is the default behavior when no requirement or local that such reuse is the default behavior when no requirement or local
configuration prevents it. Therefore, HTTP cache requirements are configuration prevents it. Therefore, HTTP cache requirements are
focused on preventing a cache from either storing a non-reusable focused on preventing a cache from either storing a non-reusable
skipping to change at page 6, line 37 skipping to change at page 6, line 46
* contains a max-age response cache directive (see * contains a max-age response cache directive (see
Section 5.2.2.8), or Section 5.2.2.8), or
* contains a s-maxage response cache directive (see * contains a s-maxage response cache directive (see
Section 5.2.2.9) and the cache is shared, or Section 5.2.2.9) and the cache is shared, or
* contains a Cache Control Extension (see Section 5.2.3) that * contains a Cache Control Extension (see Section 5.2.3) that
allows it to be cached, or allows it to be cached, or
* has a status code that is defined as cacheable (see * has a status code that is defined as cacheable by default (see
Section 4.2.2), or Section 4.2.2), or
* contains a public response cache directive (see * contains a public response cache directive (see
Section 5.2.2.5). Section 5.2.2.5).
Note that any of the requirements listed above can be overridden by a Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 5.2.3. cache-control extension; see Section 5.2.3.
In this context, a cache has "understood" a request method or a In this context, a cache has "understood" a request method or a
response status code if it recognizes it and implements all specified response status code if it recognizes it and implements all specified
skipping to change at page 12, line 45 skipping to change at page 13, line 4
a cache MAY assign a heuristic expiration time when an explicit time a cache MAY assign a heuristic expiration time when an explicit time
is not specified, employing algorithms that use other header field is not specified, employing algorithms that use other header field
values (such as the Last-Modified time) to estimate a plausible values (such as the Last-Modified time) to estimate a plausible
expiration time. This specification does not provide specific expiration time. This specification does not provide specific
algorithms, but does impose worst-case constraints on their results. algorithms, but does impose worst-case constraints on their results.
A cache MUST NOT use heuristics to determine freshness when an A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response. Because explicit expiration time is present in the stored response. Because
of the requirements in Section 3, this means that, effectively, of the requirements in Section 3, this means that, effectively,
heuristics can only be used on responses without explicit freshness heuristics can only be used on responses without explicit freshness
whose status codes are defined as cacheable, and responses without whose status codes are defined as cacheable by default (see Section
explicit freshness that have been marked as explicitly cacheable 6.1 of [Part2]), and those responses without explicit freshness that
(e.g., with a "public" response cache directive). have been marked as explicitly cacheable (e.g., with a "public"
response cache directive).
If the response has a Last-Modified header field (Section 2.2 of If the response has a Last-Modified header field (Section 2.2 of
[Part4]), caches are encouraged to use a heuristic expiration value [Part4]), caches are encouraged to use a heuristic expiration value
that is no more than some fraction of the interval since that time. that is no more than some fraction of the interval since that time.
A typical setting of this fraction might be 10%. A typical setting of this fraction might be 10%.
When a heuristic is used to calculate freshness lifetime, a cache When a heuristic is used to calculate freshness lifetime, a cache
SHOULD generate a Warning header field with a 113 warn-code (see SHOULD generate a Warning header field with a 113 warn-code (see
Section 5.5.4) in the response if its current_age is more than 24 Section 5.5.4) in the response if its current_age is more than 24
hours and such a warning is not already present. hours and such a warning is not already present.
skipping to change at page 13, line 45 skipping to change at page 14, line 8
date_value date_value
The term "date_value" denotes the value of the Date header field, The term "date_value" denotes the value of the Date header field,
in a form appropriate for arithmetic operations. See Section in a form appropriate for arithmetic operations. See Section
7.1.1.2 of [Part2] for the definition of the Date header field, 7.1.1.2 of [Part2] for the definition of the Date header field,
and for requirements regarding responses without it. and for requirements regarding responses without it.
now now
The term "now" means "the current value of the clock at the host The term "now" means "the current value of the clock at the host
performing the calculation". A host ought to use NTP ([RFC1305]) performing the calculation". A host ought to use NTP ([RFC5905])
or some similar protocol to synchronize its clocks to Coordinated or some similar protocol to synchronize its clocks to Coordinated
Universal Time. Universal Time.
request_time request_time
The current value of the clock at the host at the time the request The current value of the clock at the host at the time the request
resulting in the stored response was made. resulting in the stored response was made.
response_time response_time
skipping to change at page 21, line 42 skipping to change at page 21, line 52
Argument syntax: Argument syntax:
delta-seconds (see Section 1.2.1) delta-seconds (see Section 1.2.1)
The "max-age" request directive indicates that the client is The "max-age" request directive indicates that the client is
unwilling to accept a response whose age is greater than the unwilling to accept a response whose age is greater than the
specified number of seconds. Unless the max-stale request directive specified number of seconds. Unless the max-stale request directive
is also present, the client is not willing to accept a stale is also present, the client is not willing to accept a stale
response. response.
Note: This directive uses the token form of the argument syntax; This directive uses the token form of the argument syntax; e.g.,
e.g., 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the
the quoted-string form. quoted-string form.
5.2.1.2. max-stale 5.2.1.2. max-stale
Argument syntax: Argument syntax:
delta-seconds (see Section 1.2.1) delta-seconds (see Section 1.2.1)
The "max-stale" request directive indicates that the client is The "max-stale" request directive indicates that the client is
willing to accept a response that has exceeded its freshness willing to accept a response that has exceeded its freshness
lifetime. If max-stale is assigned a value, then the client is lifetime. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its freshness lifetime willing to accept a response that has exceeded its freshness lifetime
by no more than the specified number of seconds. If no value is 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 assigned to max-stale, then the client is willing to accept a stale
response of any age. response of any age.
Note: This directive uses the token form of the argument syntax; This directive uses the token form of the argument syntax; e.g.,
e.g., 'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT 'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT generate
generate the quoted-string form. the quoted-string form.
5.2.1.3. min-fresh 5.2.1.3. min-fresh
Argument syntax: Argument syntax:
delta-seconds (see Section 1.2.1) delta-seconds (see Section 1.2.1)
The "min-fresh" request directive indicates that the client is The "min-fresh" request directive indicates that the client is
willing to accept a response whose freshness lifetime is no less than willing to accept a response whose freshness lifetime is no less than
its current age plus the specified time in seconds. That is, the 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 client wants a response that will still be fresh for at least the
specified number of seconds. specified number of seconds.
Note: This directive uses the token form of the argument syntax; This directive uses the token form of the argument syntax; e.g.,
e.g., 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT generate
generate the quoted-string form. the quoted-string form.
5.2.1.4. no-cache 5.2.1.4. no-cache
The "no-cache" request directive indicates that a cache MUST NOT use The "no-cache" request directive indicates that a cache MUST NOT use
a stored response to satisfy the request without successful a stored response to satisfy the request without successful
validation on the origin server. validation on the origin server.
5.2.1.5. no-store 5.2.1.5. no-store
The "no-store" request directive indicates that a cache MUST NOT The "no-store" request directive indicates that a cache MUST NOT
skipping to change at page 24, line 19 skipping to change at page 24, line 29
subject to any other restrictions on caching. However, any header subject to any other restrictions on caching. However, any header
fields in the response that have the field-name(s) listed MUST NOT be fields in the response that have the field-name(s) listed MUST NOT be
sent in the response to a subsequent request without successful sent in the response to a subsequent request without successful
revalidation with the origin server. This allows an origin server to revalidation with the origin server. This allows an origin server to
prevent the re-use of certain header fields in a response, while prevent the re-use of certain header fields in a response, while
still allowing caching of the rest of the response. still allowing caching of the rest of the response.
The field-names given are not limited to the set of header fields The field-names given are not limited to the set of header fields
defined by this specification. Field names are case-insensitive. defined by this specification. Field names are case-insensitive.
This directive uses the quoted-string form of the argument syntax. A
sender SHOULD NOT generate the token form (even if quoting appears
not to be needed for single-entry lists).
Note: Although it has been back-ported to many implementations, some Note: Although it has been back-ported to many implementations, some
HTTP/1.0 caches will not recognize or obey this directive. Also, no- HTTP/1.0 caches will not recognize or obey this directive. Also, no-
cache response directives with field-names are often handled by cache response directives with field-names are often handled by
caches as if an unqualified no-cache directive was received; i.e., caches as if an unqualified no-cache directive was received; i.e.,
the special handling for the qualified form is not widely the special handling for the qualified form is not widely
implemented. implemented.
Note: This directive uses the quoted-string form of the argument
syntax. A sender SHOULD NOT generate the token form (even if quoting
appears not to be needed for single-entry lists).
5.2.2.3. no-store 5.2.2.3. no-store
The "no-store" response directive indicates that a cache MUST NOT The "no-store" response directive indicates that a cache MUST NOT
store any part of either the immediate request or response. This store any part of either the immediate request or response. This
directive applies to both private and shared caches. "MUST NOT directive applies to both private and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a best- store the information in non-volatile storage, and MUST make a best-
effort attempt to remove the information from volatile storage as effort attempt to remove the information from volatile storage as
promptly as possible after forwarding it. promptly as possible after forwarding it.
skipping to change at page 25, line 13 skipping to change at page 25, line 20
payload, as defined in Section 5.7.2 of [Part1]. payload, as defined in Section 5.7.2 of [Part1].
5.2.2.5. public 5.2.2.5. public
The "public" response directive indicates that any cache MAY store The "public" response directive indicates that any cache MAY store
the response, even if the response would normally be non-cacheable or the response, even if the response would normally be non-cacheable or
cacheable only within a private cache. (See Section 3.2 for cacheable only within a private cache. (See Section 3.2 for
additional details related to the use of public in response to a additional details related to the use of public in response to a
request containing Authorization, and Section 3 for details of how request containing Authorization, and Section 3 for details of how
public affects responses that would normally not be stored, due to public affects responses that would normally not be stored, due to
their status codes not being defined as cacheable.) their status codes not being defined as cacheable by default; see
Section 4.2.2.)
5.2.2.6. private 5.2.2.6. private
Argument syntax: Argument syntax:
#field-name #field-name
The "private" response directive indicates that the response message The "private" response directive indicates that the response message
is intended for a single user and MUST NOT be stored by a shared is intended for a single user and MUST NOT be stored by a shared
cache. A private cache MAY store the response and reuse it for later cache. A private cache MAY store the response and reuse it for later
skipping to change at page 25, line 35 skipping to change at page 25, line 43
If the private response directive specifies one or more field-names, If the private response directive specifies one or more field-names,
this requirement is limited to the field-values associated with the this requirement is limited to the field-values associated with the
listed response header fields. That is, a shared cache MUST NOT listed response header fields. That is, a shared cache MUST NOT
store the specified field-names(s), whereas it MAY store the store the specified field-names(s), whereas it MAY store the
remainder of the response message. remainder of the response message.
The field-names given are not limited to the set of header fields The field-names given are not limited to the set of header fields
defined by this specification. Field names are case-insensitive. defined by this specification. Field names are case-insensitive.
This directive uses the quoted-string form of the argument syntax. A
sender SHOULD NOT generate the token form (even if quoting appears
not to be needed for single-entry lists).
Note: This usage of the word "private" only controls where the Note: This usage of the word "private" only controls where the
response can be stored; it cannot ensure the privacy of the message response can be stored; it cannot ensure the privacy of the message
content. Also, private response directives with field-names are content. Also, private response directives with field-names are
often handled by caches as if an unqualified private directive was often handled by caches as if an unqualified private directive was
received; i.e., the special handling for the qualified form is not received; i.e., the special handling for the qualified form is not
widely implemented. widely implemented.
Note: This directive uses the quoted-string form of the argument
syntax. A sender SHOULD NOT generate the token form (even if quoting
appears not to be needed for single-entry lists).
5.2.2.7. proxy-revalidate 5.2.2.7. proxy-revalidate
The "proxy-revalidate" response directive has the same meaning as the The "proxy-revalidate" response directive has the same meaning as the
must-revalidate response directive, except that it does not apply to must-revalidate response directive, except that it does not apply to
private caches. private caches.
5.2.2.8. max-age 5.2.2.8. max-age
Argument syntax: Argument syntax:
delta-seconds (see Section 1.2.1) delta-seconds (see Section 1.2.1)
The "max-age" response directive indicates that the response is to be The "max-age" response directive indicates that the response is to be
considered stale after its age is greater than the specified number considered stale after its age is greater than the specified number
of seconds. of seconds.
Note: This directive uses the token form of the argument syntax; This directive uses the token form of the argument syntax; e.g.,
e.g., 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the
the quoted-string form. quoted-string form.
5.2.2.9. s-maxage 5.2.2.9. s-maxage
Argument syntax: Argument syntax:
delta-seconds (see Section 1.2.1) delta-seconds (see Section 1.2.1)
The "s-maxage" response directive indicates that, in shared caches, The "s-maxage" response directive indicates that, in shared caches,
the maximum age specified by this directive overrides the maximum age the maximum age specified by this directive overrides the maximum age
specified by either the max-age directive or the Expires header specified by either the max-age directive or the Expires header
field. The s-maxage directive also implies the semantics of the field. The s-maxage directive also implies the semantics of the
proxy-revalidate response directive. proxy-revalidate response directive.
Note: This directive uses the token form of the argument syntax; This directive uses the token form of the argument syntax; e.g.,
e.g., 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the
generate the quoted-string form. quoted-string form.
5.2.3. Cache Control Extensions 5.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value. or more cache-extension tokens, each with an optional value.
Informational extensions (those that do not require a change in cache Informational extensions (those that do not require a change in cache
behavior) can be added without changing the semantics of other behavior) can be added without changing the semantics of other
directives. Behavioral extensions are designed to work by acting as directives. Behavioral extensions are designed to work by acting as
modifiers to the existing base of cache directives. modifiers to the existing base of cache directives.
skipping to change at page 32, line 12 skipping to change at page 32, line 18
This does not prohibit the history mechanism from telling the user This does not prohibit the history mechanism from telling the user
that a view might be stale, or from honoring cache directives (e.g., that a view might be stale, or from honoring cache directives (e.g.,
Cache-Control: no-store). Cache-Control: no-store).
7. IANA Considerations 7. IANA Considerations
7.1. Cache Directive Registry 7.1. Cache Directive Registry
The HTTP Cache Directive Registry defines the name space for the The HTTP Cache Directive Registry defines the name space for the
cache directives. It will be created and maintained at cache directives. It will be created and maintained at (the
suggested URI)
<http://www.iana.org/assignments/http-cache-directives>. <http://www.iana.org/assignments/http-cache-directives>.
7.1.1. Procedure 7.1.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Cache Directive Name o Cache Directive Name
o Pointer to specification text o Pointer to specification text
skipping to change at page 33, line 27 skipping to change at page 33, line 32
| proxy-revalidate | Section 5.2.2.7 | | proxy-revalidate | Section 5.2.2.7 |
| public | Section 5.2.2.5 | | public | Section 5.2.2.5 |
| s-maxage | Section 5.2.2.9 | | s-maxage | Section 5.2.2.9 |
| stale-if-error | [RFC5861], Section 4 | | stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 | | stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+----------------------------------+ +------------------------+----------------------------------+
7.2. Warn Code Registry 7.2. Warn Code Registry
The HTTP Warn Code Registry defines the name space for warn codes. The HTTP Warn Code Registry defines the name space for warn codes.
It will be created and maintained at It will be created and maintained at (the suggested URI)
<http://www.iana.org/assignments/http-warn-codes>. <http://www.iana.org/assignments/http-warn-codes>.
7.2.1. Procedure 7.2.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Warn Code (3 digits) o Warn Code (3 digits)
o Short Description o Short Description
skipping to change at page 35, line 38 skipping to change at page 35, line 38
9. Acknowledgments 9. Acknowledgments
See Section 10 of [Part1]. See Section 10 of [Part1].
10. References 10. References
10.1. Normative References 10.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-24 (work in progress), draft-ietf-httpbis-p1-messaging-25 (work in progress),
September 2013. November 2013.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-24 (work in progress), draft-ietf-httpbis-p2-semantics-25 (work in progress),
September 2013. November 2013.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-24 (work in progress), draft-ietf-httpbis-p4-conditional-25 (work in progress),
September 2013. November 2013.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-24 (work in progress), draft-ietf-httpbis-p5-range-25 (work in progress),
September 2013. November 2013.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-24 (work in progress), draft-ietf-httpbis-p7-auth-25 (work in progress),
September 2013. November 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, April 2010. Content", RFC 5861, April 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
Appendix A. Changes from RFC 2616 Appendix A. Changes from RFC 2616
The specification has been substantially rewritten for clarity. The specification has been substantially rewritten for clarity.
The conditions under which an authenticated response can be cached The conditions under which an authenticated response can be cached
have been clarified. (Section 3.2) have been clarified. (Section 3.2)
skipping to change at page 39, line 49 skipping to change at page 39, line 49
warn-agent = ( uri-host [ ":" port ] ) / pseudonym warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
] ]
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
Changes up to the first Working Group Last Call draft are summarized Changes up to the IETF Last Call draft are summarized in <http://
in <http://trac.tools.ietf.org/html/ trac.tools.ietf.org/html/draft-ietf-httpbis-p6-cache-24#appendix-D>.
draft-ietf-httpbis-p6-cache-19#appendix-C>.
D.1. Since draft-ietf-httpbis-p6-cache-19
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/307>: "untangle
Cache-Control ABNF"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/353>: "Multiple
values in Cache-Control header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/355>: "Case
sensitivity of header fields in CC values"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/356>: "Spurious
'MAYs'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance
considerations for new cache control directives"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
introduction of new IANA registries as normative changes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/373>: "broken prose
in description of 'Vary'"
D.2. Since draft-ietf-httpbis-p6-cache-20
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/375>: "'Most
Conservative'"
Other changes:
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
o Move definition of "Vary" header field into Part 2.
o Add security considerations with respect to cache poisoning and
the "Set-Cookie" header field.
D.3. Since draft-ietf-httpbis-p6-cache-21
Closed issues:
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/406>: "304 without
validator"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/430>: "Revert prior
change to the meaning of the public cache response directive.
D.4. Since draft-ietf-httpbis-p6-cache-22 D.1. Since draft-ietf-httpbis-p6-cache-24
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
expansion in ABNF appendices" needs to be updated to 5905"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/453>: "Returning the
freshest response"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
extension point considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/469>: "Editorial
notes for p6"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/471>: "Vary and
future requests"
D.5. Since draft-ietf-httpbis-p6-cache-23
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/486>: "Requiring o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling
proxies to process warn-date" reference to cacheable status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/496>: "add Warning o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR
header field examples" review of draft-ietf-httpbis-p6-cache-24"
Index Index
1 1
110 (warn-code) 30 110 (warn-code) 31
111 (warn-code) 31 111 (warn-code) 31
112 (warn-code) 31 112 (warn-code) 31
113 (warn-code) 31 113 (warn-code) 31
199 (warn-code) 31 199 (warn-code) 31
2 2
214 (warn-code) 31 214 (warn-code) 31
299 (warn-code) 31 299 (warn-code) 31
A A
age 10 age 10
Age header field 20 Age header field 20
C C
cache 4 cache 4
cache entry 5 cache entry 5
cache key 5 cache key 5
Cache-Control header field 20 Cache-Control header field 21
D D
Disconnected Operation (warn-text) 31 Disconnected Operation (warn-text) 31
E E
Expires header field 27 Expires header field 27
explicit expiration time 10 explicit expiration time 10
F F
fresh 10 fresh 10
skipping to change at page 43, line 9 skipping to change at page 41, line 26
warn-text 29 warn-text 29
Warning 29 Warning 29
warning-value 29 warning-value 29
H H
Heuristic Expiration (warn-text) 31 Heuristic Expiration (warn-text) 31
heuristic expiration time 10 heuristic expiration time 10
M M
max-age (cache directive) 21, 26 max-age (cache directive) 21, 26
max-stale (cache directive) 21 max-stale (cache directive) 22
min-fresh (cache directive) 22 min-fresh (cache directive) 22
Miscellaneous Persistent Warning (warn-text) 31 Miscellaneous Persistent Warning (warn-text) 31
Miscellaneous Warning (warn-text) 31 Miscellaneous Warning (warn-text) 31
must-revalidate (cache directive) 23 must-revalidate (cache directive) 23
N N
no-cache (cache directive) 22-23 no-cache (cache directive) 22, 24
no-store (cache directive) 22, 24 no-store (cache directive) 22, 24
no-transform (cache directive) 23-24 no-transform (cache directive) 23, 25
O O
only-if-cached (cache directive) 23 only-if-cached (cache directive) 23
P P
Pragma header field 28 Pragma header field 28
private (cache directive) 25 private (cache directive) 25
private cache 4 private cache 4
proxy-revalidate (cache directive) 25 proxy-revalidate (cache directive) 26
public (cache directive) 25 public (cache directive) 25
R R
Response is Stale (warn-text) 30 Response is Stale (warn-text) 31
Revalidation Failed (warn-text) 31 Revalidation Failed (warn-text) 31
S S
s-maxage (cache directive) 26 s-maxage (cache directive) 26
shared cache 4 shared cache 4
stale 10 stale 10
strong validator 18 strong validator 18
T T
Transformation Applied (warn-text) 31 Transformation Applied (warn-text) 31
 End of changes. 47 change blocks. 
160 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/