--- 1/draft-ietf-httpbis-p6-cache-20.txt 2012-10-04 12:14:26.409425480 +0200 +++ 2/draft-ietf-httpbis-p6-cache-21.txt 2012-10-04 12:14:26.485426137 +0200 @@ -1,61 +1,58 @@ HTTPbis Working Group R. Fielding, Ed. Internet-Draft Adobe -Obsoletes: 2616 (if approved) Y. Lafon, Ed. -Intended status: Standards Track W3C -Expires: January 17, 2013 M. Nottingham, Ed. - Rackspace - J. Reschke, Ed. +Obsoletes: 2616 (if approved) M. Nottingham, Ed. +Intended status: Standards Track Akamai +Expires: April 7, 2013 J. Reschke, Ed. greenbytes - July 16, 2012 + October 4, 2012 - HTTP/1.1, part 6: Caching - draft-ietf-httpbis-p6-cache-20 + Hypertext Transfer Protocol (HTTP/1.1): Caching + draft-ietf-httpbis-p6-cache-21 Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at . The current issues list is at and related documents (including fancy diffs) can be found at . - The changes in this draft are summarized in Appendix D.1. + The changes in this draft are summarized in Appendix D.2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 17, 2013. + This Internet-Draft will expire on April 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,72 +73,72 @@ not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 6 - 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 - 1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 7 - 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 7 - 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 8 - 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 9 - 3.2. Storing Responses to Authenticated Requests . . . . . . . 9 - 4. Constructing Responses from Caches . . . . . . . . . . . . . . 10 - 4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 - 4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 + 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 + 1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 6 + 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 + 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 + 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 8 + 3.2. Storing Responses to Authenticated Requests . . . . . . . 8 + 4. Constructing Responses from Caches . . . . . . . . . . . . . . 9 + 4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 4.1.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 - 4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 - 4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 - 4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 + 4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 12 + 4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 14 + 4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Freshening Responses with 304 Not Modified . . . . . . 16 - 4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 17 - 4.4. Combining Partial Content . . . . . . . . . . . . . . . . 18 - 5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 19 - 6. Request Methods that Invalidate . . . . . . . . . . . . . . . 19 - 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 - 7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 16 + 4.4. Combining Partial Content . . . . . . . . . . . . . . . . 17 + 5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 18 + 6. Request Methods that Invalidate . . . . . . . . . . . . . . . 18 + 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19 + 7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 - 7.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 - 7.2.2. Response Cache-Control Directives . . . . . . . . . . 23 - 7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 - 7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 7.2.1. Request Cache-Control Directives . . . . . . . . . . . 20 + 7.2.2. Response Cache-Control Directives . . . . . . . . . . 22 + 7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25 + 7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 7.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 7.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 7.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 - 7.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 32 - 7.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 32 - 7.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32 - 7.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32 - 7.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32 - 7.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32 - 7.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 - 8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 33 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33 - 9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 34 - 9.3. Header Field Registration . . . . . . . . . . . . . . . . 34 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 - Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 - Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 37 - Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 + 7.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 7.5.1. 110 Response is Stale . . . . . . . . . . . . . . . . 30 + 7.5.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 30 + 7.5.3. 112 Disconnected Operation . . . . . . . . . . . . . . 30 + 7.5.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 30 + 7.5.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 30 + 7.5.6. 214 Transformation Applied . . . . . . . . . . . . . . 30 + 7.5.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 + 7.5.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 31 + 8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31 + 9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 32 + 9.3. Header Field Registration . . . . . . . . . . . . . . . . 33 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 + Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 + Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 35 + Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 37 Appendix D. Change Log (to be removed by RFC Editor before - publication) . . . . . . . . . . . . . . . . . . . . 39 - D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 39 + publication) . . . . . . . . . . . . . . . . . . . . 38 + D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 38 + D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 38 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages. 1.1. Purpose @@ -229,65 +226,33 @@ validator A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an equivalent copy of a representation. See Section 2.1 of [Part4]. strong validator A validator that is defined by the origin server such that its - current value will change if the representation body changes; + current value will change if the representation data changes; i.e., an entity-tag that is not marked as weak (Section 2.3 of [Part4]) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by Section 2.2.2 of [Part4]. 1.3. Conformance and Error Handling The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - This specification targets conformance criteria according to the role - of a participant in HTTP communication. Hence, HTTP requirements are - placed on senders, recipients, clients, servers, user agents, - intermediaries, origin servers, proxies, gateways, or caches, - depending on what behavior is being constrained by the requirement. - See Section 2 of [Part1] for definitions of these terms. - - The verb "generate" is used instead of "send" where a requirement - differentiates between creating a protocol element and merely - forwarding a received element downstream. - - An implementation is considered conformant if it complies with all of - the requirements associated with the roles it partakes in HTTP. Note - that SHOULD-level requirements are relevant here, unless one of the - documented exceptions is applicable. - - This document also uses ABNF to define valid protocol elements - (Section 1.4). In addition to the prose requirements placed upon - them, senders MUST NOT generate protocol elements that do not match - the grammar defined by the ABNF rules for those protocol elements - that are applicable to the sender's role. If a received protocol - element is processed, the recipient MUST be able to parse any value - that would match the ABNF rules for that protocol element, excluding - only those rules not applicable to the recipient's role. - - Unless noted otherwise, a recipient MAY attempt to recover a usable - protocol element from an invalid construct. HTTP does not define - specific error handling mechanisms except when they have a direct - impact on security, since different applications of the protocol - require different error handling strategies. For example, a Web - browser might wish to transparently recover from a response where the - Location header field doesn't parse according to the ABNF, whereas a - systems control client might consider any form of error recovery to - be dangerous. + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [Part1]. 1.4. Syntax Notation This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with the list rule extension defined in Section 1.2 of [Part1]. Appendix B describes rules imported from other documents. Appendix C shows the collected ABNF with the list rule expanded. 1.4.1. Delta Seconds @@ -456,21 +421,21 @@ Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 7.2.3. When a stored response is used to satisfy a request without validation, a cache MUST include a single Age header field (Section 7.1) in the response with a value equal to the stored response's current_age; see Section 4.1.3. A cache MUST write through requests with methods that are unsafe - (Section 2.1.1 of [Part2]) to the origin server; i.e., a cache is not + (Section 5.2.1 of [Part2]) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response. Also, note that unsafe requests might invalidate already stored responses; see Section 6. When more than one suitable response is stored, a cache MUST use the most recent response (as determined by the Date header field). It can also forward a request with "Cache-Control: max-age=0" or "Cache- Control: no-cache" to disambiguate which response to use. @@ -548,21 +513,21 @@ When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control: max-age directives), it is considered invalid. Caches are encouraged to consider responses that have invalid freshness information to be stale. 4.1.2. Calculating Heuristic Freshness If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness to be - used (including the following in Section 4 of [Part2]: 200 (OK), 203 + used (including the following in Section 7 of [Part2]: 200 (OK), 203 (Non-Authoritative Information), 206 (Partial Content), 300 (Multiple Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY calculate a heuristic expiration time. A cache MUST NOT use heuristics to determine freshness for responses with status codes that do not explicitly allow it. When a heuristic is used to calculate freshness lifetime, a cache SHOULD attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already present. @@ -596,22 +561,22 @@ The term "age_value" denotes the value of the Age header field (Section 7.1), in a form appropriate for arithmetic operation; or 0, if not available. date_value HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic - operations. See Section 9.10 of [Part2] for the definition of the - Date header field, and for requirements regarding responses + operations. See Section 8.1.1.2 of [Part2] for the definition of + the Date header field, and for requirements regarding responses without it. now The term "now" means "the current value of the clock at the host performing the calculation". A cache SHOULD use NTP ([RFC1305]) or some similar protocol to synchronize its clocks to a globally accurate time standard. request_time @@ -652,60 +617,58 @@ The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response was last validated by the origin server to the corrected_initial_age. resident_time = now - response_time; current_age = corrected_initial_age + resident_time; Additionally, to avoid common problems in date parsing: - o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date - which appears to be more than 50 years in the future is in fact in - the past (this helps solve the "year 2000" problem). + o Recipients SHOULD assume that an RFC-850 date which appears to be + more than 50 years in the future is in fact in the past (this + helps solve the "year 2000" problem). o Although all date formats are specified to be case-sensitive, recipients SHOULD match day, week and timezone names case- insensitively. - o An HTTP/1.1 implementation MAY internally represent a parsed - Expires date as earlier than the proper value, but MUST NOT - internally represent a parsed Expires date as later than the - proper value. + o An implementation MAY internally represent a parsed Expires date + as earlier than the proper value, but MUST NOT internally + represent a parsed Expires date as later than the proper value. - o All expiration-related calculations MUST be done in GMT. The - local time zone MUST NOT influence the calculation or comparison - of an age or expiration time. + o Recipients MUST perform all expiration-related calculations in + GMT. The local time zone MUST NOT influence the calculation or + comparison of an age or expiration time. - o If an HTTP header field incorrectly carries a date value with a - time zone other than GMT, it MUST be converted into GMT using the - most conservative possible conversion. + o Caches SHOULD consider dates with time zones other than "GMT" + invalid. 4.1.4. Serving Stale Responses A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but is not fresh according to the calculations in Section 4.1. A cache MUST NOT return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 7.2.2). A cache MUST NOT return stale responses unless it is disconnected (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- stale request directive; see Section 7.2.1). A cache SHOULD append a Warning header field with the 110 warn-code - (see Section 7.6) to stale responses. Likewise, a cache SHOULD add + (see Section 7.5) to stale responses. Likewise, a cache SHOULD add the 112 warn-code to stale responses if the cache is disconnected. If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache can forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because that response became stale in transit. @@ -730,21 +693,21 @@ responses contains only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored response. Cache handling of a response to a conditional request is dependent upon its status code: o A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see Section 4.2.1. - o A full response (i.e., one with a response body) indicates that + o A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request is suitable. Instead, the cache can use the full response to satisfy the request and MAY replace the stored response(s). o However, if a cache receives a 5xx (Server Error) response while attempting to validate a response, it can either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it can return a previously stored response (see Section 4.1.4). @@ -767,36 +730,37 @@ corresponds to one of the cache's stored responses, then the most recent of those matching stored responses is selected. o If the new response does not include any form of validator, there is only one stored response, and that stored response also lacks a validator, then that stored response is selected. If a stored response is selected for update, the cache MUST: o delete any Warning header fields in the stored response with warn- - code 1xx (see Section 7.6); + code 1xx (see Section 7.5); o retain any Warning header fields in the stored response with warn- code 2xx; and, o use other header fields provided in the 304 (Not Modified) response to replace all instances of the corresponding header fields in the stored response. 4.3. Using Negotiated Responses When a cache receives a request that can be satisfied by a stored - response that has a Vary header field (Section 7.5), it MUST NOT use - that response unless all of the selecting header fields nominated by - the Vary header field match in both the original request (i.e., that - associated with the stored response), and the presented request. + response that has a Vary header field (Section 8.2.1 of [Part2]), it + MUST NOT use that response unless all of the selecting header fields + nominated by the Vary header field match in both the original request + (i.e., that associated with the stored response), and the presented + request. The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following: o adding or removing whitespace, where allowed in the header field's syntax o combining multiple header fields with the same field name (see Section 3.2 of [Part1]) @@ -834,21 +798,21 @@ might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in Section 4.2 of [Part5]. When combining the new response with one or more stored responses, a cache MUST: o delete any Warning header fields in the stored response with warn- - code 1xx (see Section 7.6); + code 1xx (see Section 7.5); o retain any Warning header fields in the stored response with warn- code 2xx; and, o use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response. 5. Updating Caches with HEAD Responses @@ -862,32 +826,32 @@ Last-Modified value of a HEAD response differs from that in a selected GET response, the cache MUST consider that selected response to be stale. If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected GET response (as per Section 4.3), the cache SHOULD update the remaining header fields in the stored response using the following rules: o delete any Warning header fields in the stored response with warn- - code 1xx (see Section 7.6); + code 1xx (see Section 7.5); o retain any Warning header fields in the stored response with warn- code 2xx; and, o use other header fields provided in the response to replace all instances of the corresponding header fields in the stored response. 6. Request Methods that Invalidate - Because unsafe request methods (Section 2.1.1 of [Part2]) such as + Because unsafe request methods (Section 5.2.1 of [Part2]) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. A cache MUST invalidate the effective Request URI (Section 5.5 of [Part1]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response to a request with an unsafe method is received. However, a cache MUST NOT invalidate a URI from a Location or @@ -1281,21 +1245,22 @@ The "Expires" header field gives the date/time after which the response is considered stale. See Section 4.1 for further discussion of the freshness model. The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time. The field-value is an absolute date and time as defined by HTTP-date - in Section 5.1 of [Part2]; a sender MUST use the rfc1123-date format. + in Section 8.1.1.1 of [Part2]; a sender MUST use the rfc1123-date + format. Expires = HTTP-date For example Expires: Thu, 01 Dec 1994 16:00:00 GMT A cache MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). @@ -1349,58 +1314,21 @@ Pragma: no-cache will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand Cache-Control from serving a cached response. Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them. -7.5. Vary - - The "Vary" header field conveys the set of header fields that were - used to select the representation. - - Caches use this information, in part, to determine whether a stored - response can be used to satisfy a given request; see Section 4.3. - - In uncacheable or stale responses, the Vary field value advises the - user agent about the criteria that were used to select the - representation. - - Vary = "*" / 1#field-name - - The set of header fields named by the Vary field value is known as - the selecting header fields. - - A server SHOULD include a Vary header field with any cacheable - response that is subject to server-driven negotiation. Doing so - allows a cache to properly interpret future requests on that resource - and informs the user agent about the presence of negotiation on that - resource. A server MAY include a Vary header field with a non- - cacheable response that is subject to server-driven negotiation, - since this might provide the user agent with useful information about - the dimensions over which the response varies at the time of the - response. - - A Vary field value of "*" signals that unspecified parameters not - limited to the header fields (e.g., the network address of the - client), play a role in the selection of the response representation; - therefore, a cache cannot determine whether this response is - appropriate. A proxy MUST NOT generate the "*" value. - - The field-names given are not limited to the set of standard header - fields defined by this specification. Field names are case- - insensitive. - -7.6. Warning +7.5. Warning The "Warning" header field is used to carry additional information about the status or transformation of a message that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message. Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguishes these responses from true failures. @@ -1456,70 +1384,71 @@ warn-date, and that warn-date is different from the Date value in the response, then that warning-value MUST be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning header fields.) If all of the warning- values are deleted for this reason, the Warning header field MUST be deleted as well. The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. -7.6.1. 110 Response is Stale +7.5.1. 110 Response is Stale A cache SHOULD include this whenever the returned response is stale. -7.6.2. 111 Revalidation Failed +7.5.2. 111 Revalidation Failed A cache SHOULD include this when returning a stale response because an attempt to validate the response failed, due to an inability to reach the server. -7.6.3. 112 Disconnected Operation +7.5.3. 112 Disconnected Operation A cache SHOULD include this if it is intentionally disconnected from the rest of the network for a period of time. -7.6.4. 113 Heuristic Expiration +7.5.4. 113 Heuristic Expiration A cache SHOULD include this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours. -7.6.5. 199 Miscellaneous Warning +7.5.5. 199 Miscellaneous Warning The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user. -7.6.6. 214 Transformation Applied +7.5.6. 214 Transformation Applied MUST be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, or modifying the representation data, unless this Warning code already appears in the response. -7.6.7. 299 Miscellaneous Persistent Warning +7.5.7. 299 Miscellaneous Persistent Warning The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action. -7.6.8. Warn Code Extensions +7.5.8. Warn Code Extensions The HTTP Warn Code Registry defines the name space for warn codes. A registration MUST include the following fields: o Warn Code (3 digits) o Short Description + o Pointer to specification text Values to be added to this name space require IETF Review (see [RFC5226], Section 4.1). The registry itself is maintained at . 8. History Lists @@ -1561,100 +1490,115 @@ | proxy-revalidate | Section 7.2.2.6 | | public | Section 7.2.2.1 | | s-maxage | Section 7.2.2.8 | | stale-if-error | [RFC5861], Section 4 | | stale-while-revalidate | [RFC5861], Section 3 | +------------------------+----------------------------------+ 9.2. Warn Code Registry The registration procedure for HTTP Warn Codes is defined by - Section 7.6.8 of this document. + Section 7.5.8 of this document. The HTTP Warn Code Registry shall be created at and be populated with the registrations below: +-----------+----------------------------------+---------------+ | Warn Code | Short Description | Reference | +-----------+----------------------------------+---------------+ - | 110 | Response is Stale | Section 7.6.1 | - | 111 | Revalidation Failed | Section 7.6.2 | - | 112 | Disconnected Operation | Section 7.6.3 | - | 113 | Heuristic Expiration | Section 7.6.4 | - | 199 | Miscellaneous Warning | Section 7.6.5 | - | 214 | Transformation Applied | Section 7.6.6 | - | 299 | Miscellaneous Persistent Warning | Section 7.6.7 | + | 110 | Response is Stale | Section 7.5.1 | + | 111 | Revalidation Failed | Section 7.5.2 | + | 112 | Disconnected Operation | Section 7.5.3 | + | 113 | Heuristic Expiration | Section 7.5.4 | + | 199 | Miscellaneous Warning | Section 7.5.5 | + | 214 | Transformation Applied | Section 7.5.6 | + | 299 | Miscellaneous Persistent Warning | Section 7.5.7 | +-----------+----------------------------------+---------------+ 9.3. Header Field Registration The Message Header Field Registry located at shall be updated with the permanent registrations below (see [RFC3864]): +-------------------+----------+----------+-------------+ | Header Field Name | Protocol | Status | Reference | +-------------------+----------+----------+-------------+ | Age | http | standard | Section 7.1 | | Cache-Control | http | standard | Section 7.2 | | Expires | http | standard | Section 7.3 | | Pragma | http | standard | Section 7.4 | - | Vary | http | standard | Section 7.5 | - | Warning | http | standard | Section 7.6 | + | Warning | http | standard | Section 7.5 | +-------------------+----------+----------+-------------+ The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 10. Security Considerations Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information. + Implementation flaws might allow attackers to insert content into a + cache ("cache poisoning"), leading to compromise of clients that + trust that content. Because of their nature, these attacks are + difficult to mitigate. + + Likewise, implementation flaws (as well as misunderstanding of cache + operation) might lead to caching of sensitive information (e.g., + authentication credentials) that is thought to be private, exposing + it to unauthorised parties. + + Note that the Set-Cookie response header [RFC6265] does not inhibit + caching; a cacheable response with a Set-Cookie header can be (and + often is) used to satisfy subsequent requests to caches. Servers who + wish to control caching of these responses are encouraged to emit + appropriate Cache-Control response headers. + 11. Acknowledgments See Section 9 of [Part1]. 12. References 12.1. Normative References - [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., - "HTTP/1.1, part 1: Message Routing and Syntax"", - draft-ietf-httpbis-p1-messaging-20 (work in progress), - July 2012. + [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + draft-ietf-httpbis-p1-messaging-21 (work in progress), + October 2012. - [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., - "HTTP/1.1, part 2: Semantics and Payloads", - draft-ietf-httpbis-p2-semantics-20 (work in progress), - July 2012. + [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", + draft-ietf-httpbis-p2-semantics-21 (work in progress), + October 2012. - [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., - "HTTP/1.1, part 4: Conditional Requests", - draft-ietf-httpbis-p4-conditional-20 (work in progress), - July 2012. + [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", + draft-ietf-httpbis-p4-conditional-21 (work in progress), + October 2012. [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., - "HTTP/1.1, part 5: Range Requests", - draft-ietf-httpbis-p5-range-20 (work in progress), - July 2012. + "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", + draft-ietf-httpbis-p5-range-21 (work in progress), + October 2012. - [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., - "HTTP/1.1, part 7: Authentication", - draft-ietf-httpbis-p7-auth-20 (work in progress), - July 2012. + [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Authentication", + draft-ietf-httpbis-p7-auth-21 (work in progress), + October 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 12.2. Informative References [RFC1305] Mills, D., "Network Time Protocol (Version 3) @@ -1668,103 +1612,101 @@ Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010. + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + Appendix A. Changes from RFC 2616 Make the specified age calculation algorithm less conservative. (Section 4.1.3) - Remove requirement to consider Content-Location in successful + Remove requirement to consider "Content-Location" in successful responses in order to determine the appropriate response to use. (Section 4.2) Clarify denial of service attack avoidance requirement. (Section 6) - Change ABNF productions for header fields to only define the field - value. (Section 7) - Do not mention RFC 2047 encoding and multiple languages in Warning + Do not mention RFC 2047 encoding and multiple languages in "Warning" header fields anymore, as these aspects never were implemented. - (Section 7.6) + (Section 7.5) Introduce Cache Directive and Warn Code Registries. (Section 7.2.3 - and Section 7.6.8) + and Section 7.5.8) Appendix B. Imported ABNF The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character). The rules below are defined in [Part1]: OWS = field-name = quoted-string = token = - port = - pseudonym = - uri-host = + port = + pseudonym = + uri-host = The rules below are defined in other parts: - HTTP-date = + HTTP-date = Appendix C. Collected ABNF Age = delta-seconds Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS cache-directive ] ) Expires = HTTP-date - HTTP-date = + HTTP-date = OWS = Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS pragma-directive ] ) - Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] - ) ) - Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] ) cache-directive = token [ "=" ( token / quoted-string ) ] delta-seconds = 1*DIGIT extension-pragma = token [ "=" ( token / quoted-string ) ] field-name = - port = + port = pragma-directive = "no-cache" / extension-pragma - pseudonym = + pseudonym = quoted-string = token = - uri-host = + uri-host = warn-agent = ( uri-host [ ":" port ] ) / pseudonym warn-code = 3DIGIT warn-date = DQUOTE HTTP-date DQUOTE warn-text = quoted-string warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date ] Appendix D. Change Log (to be removed by RFC Editor before publication) @@ -1790,173 +1732,142 @@ o : "enhance considerations for new cache control directives" o : "ABNF requirements for recipients" o : "note introduction of new IANA registries as normative changes" + o : "broken prose + in description of 'Vary'" + +D.2. Since draft-ietf-httpbis-p6-cache-20 + + Closed issues: + + o : "'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. + Index 1 - 110 Response is Stale (warn code) 31 - 111 Revalidation Failed (warn code) 32 - 112 Disconnected Operation (warn code) 32 - 113 Heuristic Expiration (warn code) 32 - 199 Miscellaneous Warning (warn code) 32 + 110 Response is Stale (warn code) 30 + 111 Revalidation Failed (warn code) 30 + 112 Disconnected Operation (warn code) 30 + 113 Heuristic Expiration (warn code) 30 + 199 Miscellaneous Warning (warn code) 30 2 - 214 Transformation Applied (warn code) 32 - 299 Miscellaneous Persistent Warning (warn code) 32 + 214 Transformation Applied (warn code) 30 + 299 Miscellaneous Persistent Warning (warn code) 31 A age 5 - Age header field 20 + Age header field 19 C cache 4 - Cache Directives - max-age 22, 25 - max-stale 22 - min-fresh 22 - must-revalidate 25 - no-cache 21, 24 - no-store 21, 25 - no-transform 23, 26 - only-if-cached 23 - private 23 - proxy-revalidate 25 - public 23 - s-maxage 26 - cache entry 7 - cache key 7 + cache entry 6 + cache key 6 Cache-Control header field 20 cacheable 4 E - Expires header field 28 + Expires header field 27 explicit expiration time 5 F first-hand 5 fresh 5 freshness lifetime 5 G Grammar - Age 20 - Cache-Control 21 - cache-directive 21 - delta-seconds 7 - Expires 28 - extension-pragma 29 - Pragma 29 - pragma-directive 29 - Vary 29 - warn-agent 30 - warn-code 30 - warn-date 30 - warn-text 30 - Warning 30 - warning-value 30 - - H - Header Fields - Age 20 + Age 19 Cache-Control 20 - Expires 28 + cache-directive 20 + delta-seconds 6 + Expires 27 + extension-pragma 28 Pragma 28 - Vary 29 - Warning 30 + pragma-directive 28 + warn-agent 29 + warn-code 29 + warn-date 29 + warn-text 29 + Warning 29 + warning-value 29 + + H heuristic expiration time 5 M - max-age - Cache Directive 22, 25 - max-stale - Cache Directive 22 - min-fresh - Cache Directive 22 - must-revalidate - Cache Directive 25 + max-age (cache directive) 21, 25 + max-stale (cache directive) 21 + min-fresh (cache directive) 22 + must-revalidate (cache directive) 24 N - no-cache - Cache Directive 21, 24 - no-store - Cache Directive 21, 25 - no-transform - Cache Directive 23, 26 + no-cache (cache directive) 20, 23 + no-store (cache directive) 20, 24 + no-transform (cache directive) 22, 25 O - only-if-cached - Cache Directive 23 + only-if-cached (cache directive) 22 P Pragma header field 28 - private - Cache Directive 23 + private (cache directive) 22 private cache 4 - proxy-revalidate - Cache Directive 25 - public - Cache Directive 23 + proxy-revalidate (cache directive) 24 + public (cache directive) 22 S - s-maxage - Cache Directive 26 + s-maxage (cache directive) 25 shared cache 4 stale 5 strong validator 6 V validator 5 strong 6 - Vary header field 29 W - Warn Codes - 110 Response is Stale 31 - 111 Revalidation Failed 32 - 112 Disconnected Operation 32 - 113 Heuristic Expiration 32 - 199 Miscellaneous Warning 32 - 214 Transformation Applied 32 - 299 Miscellaneous Persistent Warning 32 - Warning header field 30 + Warning header field 28 Authors' Addresses Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA EMail: fielding@gbiv.com URI: http://roy.gbiv.com/ - Yves Lafon (editor) - World Wide Web Consortium - W3C / ERCIM - 2004, rte des Lucioles - Sophia-Antipolis, AM 06902 - France - - EMail: ylafon@w3.org - URI: http://www.raubacapeu.net/people/yves/ - Mark Nottingham (editor) - Rackspace + Akamai EMail: mnot@mnot.net URI: http://www.mnot.net/ + Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/