p6-cache.unpg.txt   rfc7234.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7234 Adobe
Obsoletes: 2616 (if approved) M. Nottingham, Ed. Obsoletes: 2616 M. Nottingham, Ed.
Intended status: Standards Track Akamai Category: Standards Track Akamai
Expires: December 8, 2014 J. Reschke, Ed. ISSN: 2070-1721 J. Reschke, Ed.
greenbytes greenbytes
June 6, 2014 June 2014
Hypertext Transfer Protocol (HTTP/1.1): Caching Hypertext Transfer Protocol (HTTP/1.1): Caching
draft-ietf-httpbis-p6-cache-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines HTTP caches and the associated header systems. This document defines HTTP caches and the associated header
fields that control cache behavior or indicate cacheable response fields that control cache behavior or indicate cacheable response
messages. messages.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
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/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7234.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 35 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 . . . . . . . . . . . . . . . . 8 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 .................................................11
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 ....................13
4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 4.2.3. Calculating Age ....................................13
4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 4.2.4. Serving Stale Responses ............................15
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Validation ................................................16
4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15 4.3.1. Sending a Validation Request .......................16
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 .....................18
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 . . . . . . . . . . . . 19 4.3.5. Freshening Responses via HEAD ......................19
4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Invalidation ..............................................20
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 5. Header Field Definitions .......................................21
5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Age .......................................................21
5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Cache-Control .............................................21
5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 5.2.1. Request Cache-Control Directives ...................22
5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 5.2.2. Response Cache-Control Directives ..................24
5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 5.2.3. Cache Control Extensions ...........................27
5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Expires ...................................................28
5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Pragma ....................................................29
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" .............32
5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 5.5.6. Warning: 214 - "Transformation Applied" ............32
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32
6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 6. History Lists ..................................................32
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 ....33
7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32 7.1.3. Registrations ......................................33
7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 7.2. Warn Code Registry ........................................34
7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 7.2.1. Procedure ..........................................34
7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 7.2.2. Registrations ......................................34
7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 7.3. Header Field Registration .................................34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations ........................................35
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments ................................................36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References ....................................................36
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References .....................................36
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 10.2. Informative References ...................................37
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 2616 .................................38
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Imported ABNF .........................................39
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 Appendix C. Collected ABNF ........................................39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 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 14 skipping to change at page 5, line 16
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
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
A recipient parsing a delta-seconds value and converting it to binary A recipient parsing a delta-seconds value and converting it to binary
form ought to use an arithmetic type of at least 31 bits of non- form ought to use an arithmetic type of at least 31 bits of
negative integer range. If a cache receives a delta-seconds value non-negative integer range. If a cache receives a delta-seconds
greater than the greatest integer it can represent, or if any of its value greater than the greatest integer it can represent, or if any
subsequent calculations overflows, the cache MUST consider the value of its subsequent calculations overflows, the cache MUST consider the
to be either 2147483648 (2^31) or the greatest positive integer it value to be either 2147483648 (2^31) or the greatest positive integer
can conveniently represent. it can conveniently represent.
Note: The value 2147483648 is here for historical reasons, Note: The value 2147483648 is here for historical reasons,
effectively represents infinity (over 68 years), and does not need effectively represents infinity (over 68 years), and does not need
to be stored in binary form; an implementation could produce it as to be stored in binary form; an implementation could produce it as
a canned string if any overflow occurs, even if the calculations a canned string if any overflow occurs, even if the calculations
are performed with an arithmetic type incapable of directly are performed with an arithmetic type incapable of directly
representing that number. What matters here is that an overflow representing that number. What matters here is that an overflow
be detected and not treated as a negative value in later be detected and not treated as a negative value in later
calculations. calculations.
skipping to change at page 8, line 23 skipping to change at page 8, line 26
Range specifiers ([RFC7233]). After several such transfers, a cache Range specifiers ([RFC7233]). After several such transfers, a cache
might have received several ranges of the same representation. A might have received several ranges of the same representation. A
cache MAY combine these ranges into a single stored response, and cache MAY combine these ranges into a single stored response, and
reuse that response to satisfy later requests, if they all share the reuse that response to satisfy later requests, if they all share the
same strong validator and the cache complies with the client same strong validator and the cache complies with the client
requirements in Section 4.3 of [RFC7233]. requirements in Section 4.3 of [RFC7233].
When combining the new response with one or more stored responses, a When combining the new response with one or more stored responses, a
cache MUST: cache MUST:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with
code 1xx (see Section 5.5); warn-code 1xx (see Section 5.5);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with
code 2xx; and, warn-code 2xx; and,
o use other header fields provided in the new response, aside from o use other header fields provided in the new response, aside from
Content-Range, to replace all instances of the corresponding Content-Range, to replace all instances of the corresponding
header fields in the stored response. header fields in the stored response.
4. Constructing Responses from Caches 4. Constructing Responses from Caches
When presented with a request, a cache MUST NOT reuse a stored When presented with a request, a cache MUST NOT reuse a stored
response, unless: response, unless:
skipping to change at page 11, line 41 skipping to change at page 12, line 8
freshness_lifetime is defined in Section 4.2.1; current_age is freshness_lifetime is defined in Section 4.2.1; current_age is
defined in Section 4.2.3. defined in Section 4.2.3.
Clients can send the max-age or min-fresh cache directives in a Clients can send the max-age or min-fresh cache directives in a
request to constrain or relax freshness calculations for the request to constrain or relax freshness calculations for the
corresponding response (Section 5.2.1). corresponding response (Section 5.2.1).
When calculating freshness, to avoid common problems in date parsing: When calculating freshness, to avoid common problems in date parsing:
o Although all date formats are specified to be case-sensitive, a o Although all date formats are specified to be case-sensitive, a
cache recipient SHOULD match day, week, and time-zone names case- cache recipient SHOULD match day, week, and time-zone names
insensitively. case-insensitively.
o If a cache recipient's internal implementation of time has less o If a cache recipient's internal implementation of time has less
resolution than the value of an HTTP-date, the recipient MUST resolution than the value of an HTTP-date, the recipient MUST
internally represent a parsed Expires date as the nearest time internally represent a parsed Expires date as the nearest time
equal to or earlier than the received value. equal to or earlier than the received value.
o A cache recipient MUST NOT allow local time zones to influence the o A cache recipient MUST NOT allow local time zones to influence the
calculation or comparison of an age or expiration time. calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation o A cache recipient SHOULD consider a date with a zone abbreviation
skipping to change at page 15, line 22 skipping to change at page 15, line 40
according to the calculations in Section 4.2. according to the calculations in Section 4.2.
A cache MUST NOT generate a stale response if it is prohibited by an A cache MUST NOT generate a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-store" or "no-cache" explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an cache directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 5.2.2). see Section 5.2.2).
A cache MUST NOT send stale responses unless it is disconnected A cache MUST NOT send stale responses unless it is disconnected
(i.e., it cannot contact the origin server or otherwise find a (i.e., it cannot contact the origin server or otherwise find a
forward path) or doing so is explicitly allowed (e.g., by the max- forward path) or doing so is explicitly allowed (e.g., by the
stale request directive; see Section 5.2.1). max-stale request directive; see Section 5.2.1).
A cache SHOULD generate a Warning header field with the 110 warn-code A cache SHOULD generate a Warning header field with the 110 warn-code
(see Section 5.5.1) in stale responses. Likewise, a cache SHOULD (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD
generate a 112 warn-code (see Section 5.5.3) in stale responses if generate a 112 warn-code (see Section 5.5.3) in stale responses if
the cache is disconnected. the cache is disconnected.
A cache SHOULD NOT generate a new Warning header field when A cache SHOULD NOT generate a new Warning header field when
forwarding a response that does not have an Age header field, even if forwarding a response that does not have an Age header field, even if
the response is already stale. A cache need not validate a response the response is already stale. A cache need not validate a response
that merely became stale in transit. that merely became stale in transit.
skipping to change at page 16, line 6 skipping to change at page 16, line 25
4.3.1. Sending a Validation Request 4.3.1. Sending a Validation Request
When sending a conditional request for cache validation, a cache When sending a conditional request for cache validation, a cache
sends one or more precondition header fields containing validator sends one or more precondition header fields containing validator
metadata from its stored response(s), which is then compared by metadata from its stored response(s), which is then compared by
recipients to determine whether a stored response is equivalent to a recipients to determine whether a stored response is equivalent to a
current representation of the resource. current representation of the resource.
One such validator is the timestamp given in a Last-Modified header One such validator is the timestamp given in a Last-Modified header
field (Section 2.2 of [RFC7232]), which can be used in an If- field (Section 2.2 of [RFC7232]), which can be used in an
Modified-Since header field for response validation, or in an If- If-Modified-Since header field for response validation, or in an
Unmodified-Since or If-Range header field for representation If-Unmodified-Since or If-Range header field for representation
selection (i.e., the client is referring specifically to a previously selection (i.e., the client is referring specifically to a previously
obtained representation with that timestamp). obtained representation with that timestamp).
Another validator is the entity-tag given in an ETag header field Another validator is the entity-tag given in an ETag header field
(Section 2.3 of [RFC7232]). One or more entity-tags, indicating one (Section 2.3 of [RFC7232]). One or more entity-tags, indicating one
or more stored responses, can be used in an If-None-Match header or more stored responses, can be used in an If-None-Match header
field for response validation, or in an If-Match or If-Range header field for response validation, or in an If-Match or If-Range header
field for representation selection (i.e., the client is referring field for representation selection (i.e., the client is referring
specifically to one or more previously obtained representations with specifically to one or more previously obtained representations with
the listed entity-tags). the listed entity-tags).
skipping to change at page 16, line 42 skipping to change at page 17, line 12
received in that request with respect to the corresponding validators received in that request with respect to the corresponding validators
contained within the selected response. A cache MUST NOT evaluate contained within the selected response. A cache MUST NOT evaluate
conditional header fields that are only applicable to an origin conditional header fields that are only applicable to an origin
server, found in a request with semantics that cannot be satisfied server, found in a request with semantics that cannot be satisfied
with a cached response, or applied to a target resource for which it with a cached response, or applied to a target resource for which it
has no stored responses; such preconditions are likely intended for has no stored responses; such preconditions are likely intended for
some other (inbound) server. some other (inbound) server.
The proper evaluation of conditional requests by a cache depends on The proper evaluation of conditional requests by a cache depends on
the received precondition header fields and their precedence, as the received precondition header fields and their precedence, as
defined in Section 6 of [RFC7232]. The If-Match and If-Unmodified- defined in Section 6 of [RFC7232]. The If-Match and
Since conditional header fields are not applicable to a cache. If-Unmodified-Since conditional header fields are not applicable to a
cache.
A request containing an If-None-Match header field (Section 3.2 of A request containing an If-None-Match header field (Section 3.2 of
[RFC7232]) indicates that the client wants to validate one or more of [RFC7232]) indicates that the client wants to validate one or more of
its own stored responses in comparison to whichever stored response its own stored responses in comparison to whichever stored response
is selected by the cache. If the field-value is "*", or if the is selected by the cache. If the field-value is "*", or if the
field-value is a list of entity-tags and at least one of them matches field-value is a list of entity-tags and at least one of them matches
the entity-tag of the selected stored response, a cache recipient the entity-tag of the selected stored response, a cache recipient
SHOULD generate a 304 (Not Modified) response (using the metadata of SHOULD generate a 304 (Not Modified) response (using the metadata of
the selected stored response) instead of sending that stored the selected stored response) instead of sending that stored
response. response.
skipping to change at page 17, line 28 skipping to change at page 17, line 48
corresponding stored response, as updated by the 304 response corresponding stored response, as updated by the 304 response
metadata (Section 4.3.4). metadata (Section 4.3.4).
If an If-None-Match header field is not present, a request containing If an If-None-Match header field is not present, a request containing
an If-Modified-Since header field (Section 3.3 of [RFC7232]) an If-Modified-Since header field (Section 3.3 of [RFC7232])
indicates that the client wants to validate one or more of its own indicates that the client wants to validate one or more of its own
stored responses by modification date. A cache recipient SHOULD stored responses by modification date. A cache recipient SHOULD
generate a 304 (Not Modified) response (using the metadata of the generate a 304 (Not Modified) response (using the metadata of the
selected stored response) if one of the following cases is true: 1) selected stored response) if one of the following cases is true: 1)
the selected stored response has a Last-Modified field-value that is the selected stored response has a Last-Modified field-value that is
earlier than or equal to the conditional timestamp; 2) no Last- earlier than or equal to the conditional timestamp; 2) no
Modified field is present in the selected stored response, but it has Last-Modified field is present in the selected stored response, but
a Date field-value that is earlier than or equal to the conditional it has a Date field-value that is earlier than or equal to the
timestamp; or, 3) neither Last-Modified nor Date is present in the conditional timestamp; or, 3) neither Last-Modified nor Date is
selected stored response, but the cache recorded it as having been present in the selected stored response, but the cache recorded it as
received at a time earlier than or equal to the conditional having been received at a time earlier than or equal to the
timestamp. conditional timestamp.
A cache that implements partial responses to range requests, as A cache that implements partial responses to range requests, as
defined in [RFC7233], also needs to evaluate a received If-Range defined in [RFC7233], also needs to evaluate a received If-Range
header field (Section 3.2 of [RFC7233]) with respect to its selected header field (Section 3.2 of [RFC7233]) with respect to its selected
stored response. stored response.
4.3.3. Handling a Validation Response 4.3.3. Handling a Validation Response
Cache handling of a response to a conditional request is dependent Cache handling of a response to a conditional request is dependent
upon its status code: upon its status code:
skipping to change at page 18, line 43 skipping to change at page 19, line 18
o If the new response does not include any form of validator (such o If the new response does not include any form of validator (such
as in the case where a client generates an If-Modified-Since as in the case where a client generates an If-Modified-Since
request from a source other than the Last-Modified response header request from a source other than the Last-Modified response header
field), and there is only one stored response, and that stored field), and there is only one stored response, and that stored
response also lacks a validator, then that stored response is response also lacks a validator, then that stored response is
selected for update. selected for update.
If a stored response is selected for update, the cache MUST: If a stored response is selected for update, the cache MUST:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with
code 1xx (see Section 5.5); warn-code 1xx (see Section 5.5);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with
code 2xx; and, warn-code 2xx; and,
o use other header fields provided in the 304 (Not Modified) o use other header fields provided in the 304 (Not Modified)
response to replace all instances of the corresponding header response to replace all instances of the corresponding header
fields in the stored response. fields in the stored response.
4.3.5. Freshening Responses via HEAD 4.3.5. Freshening Responses via HEAD
A response to the HEAD method is identical to what an equivalent A response to the HEAD method is identical to what an equivalent
request made with a GET would have been, except it lacks a body. request made with a GET would have been, except it lacks a body.
This property of HEAD responses can be used to invalidate or update a This property of HEAD responses can be used to invalidate or update a
skipping to change at page 19, line 23 skipping to change at page 19, line 46
desired even if it has changed. desired even if it has changed.
When a cache makes an inbound HEAD request for a given request target When a cache makes an inbound HEAD request for a given request target
and receives a 200 (OK) response, the cache SHOULD update or and receives a 200 (OK) response, the cache SHOULD update or
invalidate each of its stored GET responses that could have been invalidate each of its stored GET responses that could have been
selected for that request (see Section 4.1). selected for that request (see Section 4.1).
For each of the stored responses that could have been selected, if For each of the stored responses that could have been selected, if
the stored response and HEAD response have matching values for any the stored response and HEAD response have matching values for any
received validator fields (ETag and Last-Modified) and, if the HEAD received validator fields (ETag and Last-Modified) and, if the HEAD
response has a Content-Length header field, the value of Content- response has a Content-Length header field, the value of
Length matches that of the stored response, the cache SHOULD update Content-Length matches that of the stored response, the cache SHOULD
the stored response as described below; otherwise, the cache SHOULD update the stored response as described below; otherwise, the cache
consider the stored response to be stale. SHOULD consider the stored response to be stale.
If a cache updates a stored response with the metadata provided in a If a cache updates a stored response with the metadata provided in a
HEAD response, the cache MUST: HEAD response, the cache MUST:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with
code 1xx (see Section 5.5); warn-code 1xx (see Section 5.5);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with
code 2xx; and, warn-code 2xx; and,
o use other header fields provided in the HEAD response to replace o use other header fields provided in the HEAD response to replace
all instances of the corresponding header fields in the stored all instances of the corresponding header fields in the stored
response and append new header fields to the stored response's response and append new header fields to the stored response's
header section unless otherwise restricted by the Cache-Control header section unless otherwise restricted by the Cache-Control
header field. header field.
4.4. Invalidation 4.4. Invalidation
Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as
skipping to change at page 21, line 24 skipping to change at page 21, line 47
Cache-Control directives defined elsewhere are handled. Cache-Control directives defined elsewhere are handled.
Note: Some HTTP/1.0 caches might not implement Cache-Control. Note: Some HTTP/1.0 caches might not implement Cache-Control.
A proxy, whether or not it implements a cache, MUST pass cache A proxy, whether or not it implements a cache, MUST pass cache
directives through in forwarded messages, regardless of their directives through in forwarded messages, regardless of their
significance to that application, since the directives might be significance to that application, since the directives might be
applicable to all recipients along the request/response chain. It is applicable to all recipients along the request/response chain. It is
not possible to target a directive to a specific cache. not possible to target a directive to a specific cache.
Cache directives are identified by a token, to be compared case- Cache directives are identified by a token, to be compared
insensitively, and have an optional argument, that can use both token case-insensitively, and have an optional argument, that can use both
and quoted-string syntax. For the directives defined below that token and quoted-string syntax. For the directives defined below
define arguments, recipients ought to accept both forms, even if one that define arguments, recipients ought to accept both forms, even if
is documented to be preferred. For any directive not defined by this one is documented to be preferred. For any directive not defined by
specification, a recipient MUST accept both forms. this specification, a recipient MUST accept both forms.
Cache-Control = 1#cache-directive Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ] cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor For the cache directives defined below, no argument is defined (nor
allowed) unless stated otherwise. allowed) unless stated otherwise.
5.2.1. Request Cache-Control Directives 5.2.1. Request Cache-Control Directives
skipping to change at page 23, line 5 skipping to change at page 23, line 27
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
store any part of either this request or any response to it. This store any part of either this request or any response to it. 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
effort attempt to remove the information from volatile storage as best-effort attempt to remove the information from volatile storage
promptly as possible after forwarding it. as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for ensuring This directive is NOT a reliable or sufficient mechanism for ensuring
privacy. In particular, malicious or compromised caches might not privacy. In particular, malicious or compromised caches might not
recognize or obey this directive, and communications networks might recognize or obey this directive, and communications networks might
be vulnerable to eavesdropping. be vulnerable to eavesdropping.
Note that if a request containing this directive is satisfied from a Note that if a request containing this directive is satisfied from a
cache, the no-store request directive does not apply to the already cache, the no-store request directive does not apply to the already
stored response. stored response.
skipping to change at page 24, line 34 skipping to change at page 25, line 10
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 This directive uses the quoted-string form of the argument syntax. A
sender SHOULD NOT generate the token form (even if quoting appears sender SHOULD NOT generate the token form (even if quoting appears
not to be needed for single-entry lists). 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,
cache response directives with field-names are often handled by no-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.
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
effort attempt to remove the information from volatile storage as best-effort attempt to remove the information from volatile storage
promptly as possible after forwarding it. as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for ensuring This directive is NOT a reliable or sufficient mechanism for ensuring
privacy. In particular, malicious or compromised caches might not privacy. In particular, malicious or compromised caches might not
recognize or obey this directive, and communications networks might recognize or obey this directive, and communications networks might
be vulnerable to eavesdropping. be vulnerable to eavesdropping.
5.2.2.4. no-transform 5.2.2.4. no-transform
The "no-transform" response directive indicates that an intermediary The "no-transform" response directive indicates that an intermediary
(regardless of whether it implements a cache) MUST NOT transform the (regardless of whether it implements a cache) MUST NOT transform the
skipping to change at page 30, line 38 skipping to change at page 31, line 23
Warnings have accompanying warn-text that describes the error, e.g., Warnings have accompanying warn-text that describes the error, e.g.,
for logging. It is advisory only, and its content does not affect for logging. It is advisory only, and its content does not affect
interpretation of the warn-code. interpretation of the warn-code.
If a recipient that uses, evaluates, or displays Warning header If a recipient that uses, evaluates, or displays Warning header
fields receives a warn-date that is different from the Date value in fields receives a warn-date that is different from the Date value in
the same message, the recipient MUST exclude the warning-value the same message, the recipient MUST exclude the warning-value
containing that warn-date before storing, forwarding, or using the containing that warn-date before storing, forwarding, or using the
message. This allows recipients to exclude warning-values that were message. This allows recipients to exclude warning-values that were
improperly retained after a cache validation. If all of the warning- improperly retained after a cache validation. If all of the
values are excluded, the recipient MUST exclude the Warning header warning-values are excluded, the recipient MUST exclude the Warning
field as well. header field as well.
The following warn-codes are defined by this specification, each with The following warn-codes are defined by this specification, each with
a recommended warn-text in English, and a description of its meaning. a recommended warn-text in English, and a description of its meaning.
The procedure for defining additional warn codes is described in The procedure for defining additional warn codes is described in
Section 7.2.1. Section 7.2.1.
5.5.1. Warning: 110 - "Response is Stale" 5.5.1. Warning: 110 - "Response is Stale"
A cache SHOULD generate this whenever the sent response is stale. A cache SHOULD generate this whenever the sent response is stale.
skipping to change at page 31, line 32 skipping to change at page 32, line 15
5.5.5. Warning: 199 - "Miscellaneous Warning" 5.5.5. Warning: 199 - "Miscellaneous Warning"
The warning text can include arbitrary information to be presented to The warning text can include arbitrary information to be presented to
a human user or logged. A system receiving this warning MUST NOT a human user or logged. A system receiving this warning MUST NOT
take any automated action, besides presenting the warning to the take any automated action, besides presenting the warning to the
user. user.
5.5.6. Warning: 214 - "Transformation Applied" 5.5.6. Warning: 214 - "Transformation Applied"
This Warning code MUST be added by a proxy if it applies any This Warning code MUST be added by a proxy if it applies any
transformation to the representation, such as changing the content- transformation to the representation, such as changing the
coding, media-type, or modifying the representation data, unless this content-coding, media-type, or modifying the representation data,
Warning code already appears in the response. unless this Warning code already appears in the response.
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"
The warning text can include arbitrary information to be presented to The warning text can include arbitrary information to be presented to
a human user or logged. A system receiving this warning MUST NOT a human user or logged. A system receiving this warning MUST NOT
take any automated action. take any automated action.
6. History Lists 6. History Lists
User agents often have history mechanisms, such as "Back" buttons and User agents often have history mechanisms, such as "Back" buttons and
skipping to change at page 35, line 51 skipping to change at page 36, line 36
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.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] 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",
RFC 7230, June 2014. RFC 7230, June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
draft-ietf-httpbis-p2-semantics-latest (work in progress),
June 2014. June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
draft-ietf-httpbis-p4-conditional-latest (work in June 2014.
progress), June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] 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-latest (work in progress), RFC 7233, June 2014.
June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
draft-ietf-httpbis-p7-auth-latest (work in progress),
June 2014.
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.
[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.
skipping to change at page 39, line 50 skipping to change at page 41, line 8
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
] ]
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) 32
2 2
214 (warn-code) 31 214 (warn-code) 32
299 (warn-code) 31 299 (warn-code) 32
A A
age 10 age 11
Age header field 20 Age header field 21
C C
cache 4 cache 4
cache entry 5 cache entry 5
cache key 5-6 cache key 5-6
Cache-Control header field 21 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 28
explicit expiration time 10 explicit expiration time 11
F F
fresh 10 fresh 11
freshness lifetime 10 freshness lifetime 11
G G
Grammar Grammar
Age 20 Age 21
Cache-Control 21 Cache-Control 22
cache-directive 21 cache-directive 22
delta-seconds 5 delta-seconds 5
Expires 27 Expires 28
extension-pragma 28 extension-pragma 29
Pragma 28 Pragma 29
pragma-directive 28 pragma-directive 29
warn-agent 29 warn-agent 29
warn-code 29 warn-code 29
warn-date 29 warn-date 29
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 11
M M
max-age (cache directive) 21, 26 max-age (cache directive) 22, 26
max-stale (cache directive) 22 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) 32
Miscellaneous Warning (warn-text) 31 Miscellaneous Warning (warn-text) 32
must-revalidate (cache directive) 23 must-revalidate (cache directive) 24
N N
no-cache (cache directive) 22, 24 no-cache (cache directive) 23, 25
no-store (cache directive) 22, 24 no-store (cache directive) 23, 24
no-transform (cache directive) 23, 25 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 29
private (cache directive) 25 private (cache directive) 25
private cache 4 private cache 4
proxy-revalidate (cache directive) 26 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) 30
Revalidation Failed (warn-text) 31 Revalidation Failed (warn-text) 31
S S
s-maxage (cache directive) 26 s-maxage (cache directive) 27
shared cache 4 shared cache 4
stale 10 stale 11
strong validator 18 strong validator 18
T T
Transformation Applied (warn-text) 31 Transformation Applied (warn-text) 32
V V
validator 15 validator 16
W W
Warning header field 29 Warning header field 29
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
 End of changes. 48 change blocks. 
188 lines changed or deleted 166 lines changed or added

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