--- 1/draft-ietf-httpbis-p6-cache-14.txt 2011-07-11 18:16:23.000000000 +0200 +++ 2/draft-ietf-httpbis-p6-cache-15.txt 2011-07-11 18:16:23.000000000 +0200 @@ -1,35 +1,35 @@ HTTPbis Working Group R. Fielding, Ed. Internet-Draft Adobe Obsoletes: 2616 (if approved) J. Gettys Intended status: Standards Track Alcatel-Lucent -Expires: October 20, 2011 J. Mogul +Expires: January 12, 2012 J. Mogul HP H. Frystyk Microsoft L. Masinter Adobe P. Leach Microsoft T. Berners-Lee W3C/MIT Y. Lafon, Ed. W3C M. Nottingham, Ed. J. Reschke, Ed. greenbytes - April 18, 2011 + July 11, 2011 HTTP/1.1, part 6: Caching - draft-ietf-httpbis-p6-cache-14 + draft-ietf-httpbis-p6-cache-15 Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. @@ -38,38 +38,38 @@ Discussion of this draft should take 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 C.15. + The changes in this draft are summarized in Appendix C.16. 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 October 20, 2011. + This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 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 @@ -94,43 +94,44 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.4.2. ABNF Rules defined in other Parts of the Specification . . . . . . . . . . . . . . . . . . . . 7 + 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 - 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 + 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 14 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15 - 2.6. Shared Caching of Authenticated Responses . . . . . . . . 15 + 2.6. Shared Caching of Authenticated Responses . . . . . . . . 16 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16 2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17 - 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 + 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 18 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19 3.2.2. Response Cache-Control Directives . . . . . . . . . . 21 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 27 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29 5.2. Header Field Registration . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 @@ -145,21 +146,22 @@ C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 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 @@ -286,23 +288,37 @@ quoted-string = token = OWS = 1.4.2. ABNF Rules defined in other Parts of the Specification The ABNF rules below are defined in other parts: field-name = HTTP-date = - port = + port = pseudonym = - uri-host = + uri-host = + +1.5. Delta Seconds + + The delta-seconds rule specifies a non-negative integer, representing + time in seconds. + + delta-seconds = 1*DIGIT + + If an implementation receives a delta-seconds value larger than the + largest positive integer it can represent, or if any of its + subsequent calculations overflows, it MUST consider the value to be + 2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD + use an arithmetic type of at least 31 bits of range, and senders MUST + NOT send delta-seconds with a value greater than 2147483648. 2. Cache Operation 2.1. Response Cacheability A cache MUST NOT store a response to any request, unless: o The request method is understood by the cache and defined as being cacheable, and @@ -327,23 +343,26 @@ * contains a s-maxage response cache directive and the cache is shared, or * contains a Cache Control Extension (see Section 3.2.3) that allows it to be cached, or * has a status code that can be served with heuristic freshness (see Section 2.3.1.1). + Note that any of the requirements listed above can be overridden by a + cache-control extension; see Section 3.2.3. + In this context, a cache has "understood" a request method or a response status code if it recognises it and implements any cache- - specific behaviour. In particular, 206 Partial Content responses + specific behavior. In particular, 206 Partial Content responses cannot be cached by an implementation that does not handle partial content (see Section 2.1.1). Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses. 2.1.1. Storing Partial and Incomplete Responses @@ -377,36 +396,39 @@ that would prevent its use (see Section 3.2 and Section 3.4), and o the stored response is either: * fresh (see Section 2.3), or * allowed to be served stale (see Section 2.3.3), or * successfully validated (see Section 2.4). + Note that any of the requirements listed above can be overridden by a + cache-control extension; see Section 3.2.3. + When a stored response is used to satisfy a request without validation, a cache MUST include a single Age header field (Section 3.1) in the response with a value equal to the stored response's current_age; see Section 2.3.2. A cache MUST write through requests with methods that are unsafe (Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must not 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 2.5. - A cache MUST use the most recent response (as determined by the Date - header field) when more than one suitable response is stored. It can - also forward a request with "Cache-Control: max-age=0" or "Cache- + 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. A cache that does not have a clock available MUST NOT use stored responses without revalidating them on every use. A cache, especially a shared cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize its clock with a reliable external standard. 2.3. Freshness Model @@ -440,23 +462,20 @@ response_is_fresh = (freshness_lifetime > current_age) The freshness_lifetime is defined in Section 2.3.1; the current_age is defined in Section 2.3.2. Additionally, clients might need to influence freshness calculation. They can do this using several request cache directives, with the effect of either increasing or loosening constraints on freshness. See Section 3.2.1. - [[ISSUE-no-req-for-directives: there are not requirements directly - applying to cache-request-directives and freshness.]] - Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload a resource. See Section 4 for an explanation of the difference between caches and history mechanisms. 2.3.1. Calculating Freshness Lifetime A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: @@ -634,45 +653,41 @@ suitable. Instead, a cache SHOULD use the full response to satisfy the request and MAY replace the stored response. If a cache receives a 5xx response while attempting to validate a response, it MAY either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return a previously stored response (see Section 2.3.3). 2.5. Request Methods that Invalidate - Because unsafe request methods (Section 7.1.1 of [Part2]) have the - potential for changing state on the origin server, intervening caches - can use them to keep their contents up-to-date. + Because unsafe request methods (Section 7.1.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 4.3 of [Part1]) as well as the URI(s) in the Location and Content-Location - header fields (if present) when the following request methods are - received: - - o PUT - - o DELETE - - o POST + 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 Content-Location header field if the host part of that URI differs from the host part in the effective request URI (Section 4.3 of [Part1]). This helps prevent denial of service attacks. - A cache that passes through requests with methods it does not - understand SHOULD invalidate the effective request URI (Section 4.3 - of [Part1]). + A cache SHOULD invalidate the effective request URI (Section 4.3 of + [Part1]) when it receives a non-error response to a request with a + method whose safety is unknown. - Here, "invalidate" means that the cache will either remove all stored + Here, a "non-error response" is one with a 2xx or 3xx status code. + "Invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the change at the origin server might not have gone through the cache where a response is stored. 2.6. Shared Caching of Authenticated Responses @@ -721,20 +736,24 @@ absent from a request, it can only match another request if it is also absent there. A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted by the origin server. The stored response with matching selecting header fields is known as the selected response. + If multiple selected responses are available, the most recent + response (as determined by the Date header field) is used; see + Section 2.2. + If no selected response is available, the cache MAY forward the presented request to the origin server in a conditional request; see Section 2.4. 2.8. Combining Responses When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"), it needs to create an updated response by combining the stored response with the new one, so that the updated response can be used to satisfy the @@ -777,29 +795,21 @@ 3.1. Age The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server. Age values are calculated as specified in Section 2.3.2. Age = delta-seconds Age field-values are non-negative integers, representing time in - seconds. - - delta-seconds = 1*DIGIT - - If a cache receives a value larger than the largest positive integer - it can represent, or if any of its age calculations overflows, it - MUST transmit an Age header field with a field-value of 2147483648 - (2^31). Recipients parsing the Age header field-value SHOULD use an - arithmetic type of at least 31 bits of range. + seconds (see Section 1.5). The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not true, since HTTP/1.0 caches might not implement the Age header field. 3.2. Cache-Control The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does @@ -857,24 +867,25 @@ ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already stored response. max-age - The max-age request directive indicates that the client is willing - to accept a response whose age is no greater than the specified - time in seconds. Unless the max-stale request directive is also - present, the client is not willing to accept a stale response. + The max-age request directive indicates that the client is + unwilling to accept a response whose age is greater than the + specified number of seconds. Unless the max-stale request + directive is also present, the client is not willing to accept a + stale response. max-stale The max-stale request directive indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age. @@ -890,21 +901,21 @@ no-transform The no-transform request directive indicates that an intermediary (whether or not it implements a cache) MUST NOT change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation. only-if-cached The only-if-cached request directive indicates that the client - only wishes to return a stored response. If it receives this + only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches. 3.2.2. Response Cache-Control Directives cache-response-directive = @@ -1057,26 +1068,25 @@ wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do so by including Cache-Control: private, community="UCI" A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since it will also see and understand the private directive and thus default to the safe behavior. - A cache MUST be ignore unrecognized cache directives; it is assumed - that any cache directive likely to be unrecognized by an HTTP/1.1 - cache will be combined with standard directives (or the response's - default cacheability) such that the cache behavior will remain - minimally correct even if the cache does not understand the - extension(s). + A cache MUST ignore unrecognized cache directives; it is assumed that + any cache directive likely to be unrecognized by an HTTP/1.1 cache + will be combined with standard directives (or the response's default + cacheability) such that the cache behavior will remain minimally + correct even if the cache does not understand the extension(s). The HTTP Cache Directive Registry defines the name space for the cache directives. A registration MUST include the following fields: o Cache Directive Name o Pointer to specification text @@ -1111,46 +1121,55 @@ in shared caches. A server SHOULD NOT send Expires dates more than one year in the future. A cache MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 3.4. Pragma - The "Pragma" header field is used to include implementation-specific - directives that might apply to any recipient along the request/ - response chain. All pragma directives specify optional behavior from - the viewpoint of the protocol; however, some systems MAY require that - behavior be consistent with the directives. + The "Pragma" header field allows backwards compatibility with + HTTP/1.0 caches, so that clients can specify a "no-cache" request + that they will understand (as Cache-Control was not defined until + HTTP/1.1). When the Cache-Control header is also present and + understood in a request, Pragma is ignored. + + In HTTP/1.0, Pragma was defined as an extensible field for + implementation-specified directives for recipients. This + specification deprecates such extensions to improve interoperability. Pragma = 1#pragma-directive pragma-directive = "no-cache" / extension-pragma extension-pragma = token [ "=" ( token / quoted-string ) ] - When the no-cache directive is present in a request message, a cache - SHOULD forward the request toward the origin server even if it has a - stored copy of what is being requested. This pragma directive has - the same semantics as the no-cache response directive (see - Section 3.2.2) and is defined here for backward compatibility with - HTTP/1.0. A client SHOULD include both header fields when a no-cache - request is sent to a server not known to be HTTP/1.1 compliant. A - cache SHOULD treat "Pragma: no-cache" as if the client had sent - "Cache-Control: no-cache". + When the Cache-Control header is not present in a request, the no- + cache request pragma-directive MUST have the same effect on caches as + if "Cache-Control: no-cache" were present (see Section 3.2.1). - Note: Because the meaning of "Pragma: no-cache" as a header field - is not actually specified, it does not provide a reliable - replacement for "Cache-Control: no-cache" in a response. + When sending a no-cache request, a client SHOULD include both pragma + and cache-control directives unless Cache-Control: no-cache is + purposefully omitted to target other Cache-Control response + directives at HTTP/1.1 caches. For example: - This mechanism is deprecated; no new Pragma directives will be - defined in HTTP. + GET / HTTP/1.1 + Host: www.example.com + Cache-Control: max-age=30 + 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. 3.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 2.7. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without @@ -1377,46 +1396,46 @@ suggestions and comments from individuals including: Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter. 8. References 8.1. Normative References [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, - and Message Parsing", draft-ietf-httpbis-p1-messaging-14 - (work in progress), April 2011. + and Message Parsing", draft-ietf-httpbis-p1-messaging-15 + (work in progress), July 2011. [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message - Semantics", draft-ietf-httpbis-p2-semantics-14 (work in - progress), April 2011. + Semantics", draft-ietf-httpbis-p2-semantics-15 (work in + progress), July 2011. [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional - Requests", draft-ietf-httpbis-p4-conditional-14 (work in - progress), April 2011. + Requests", draft-ietf-httpbis-p4-conditional-15 (work in + progress), July 2011. [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and - Partial Responses", draft-ietf-httpbis-p5-range-14 (work - in progress), April 2011. + Partial Responses", draft-ietf-httpbis-p5-range-15 (work + in progress), July 2011. [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", - draft-ietf-httpbis-p7-auth-14 (work in progress), - April 2011. + draft-ietf-httpbis-p7-auth-15 (work in progress), + July 2011. [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. 8.2. Informative References [RFC1305] Mills, D., "Network Time Protocol (Version 3) @@ -1489,29 +1508,29 @@ field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds ) / ( "s-maxage=" delta-seconds ) / cache-extension delta-seconds = 1*DIGIT extension-pragma = token [ "=" ( token / quoted-string ) ] field-name = - port = + port = pragma-directive = "no-cache" / extension-pragma 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 ] ABNF diagnostics: @@ -1663,20 +1682,23 @@ C.10. Since draft-ietf-httpbis-p6-cache-08 Closed issues: o : "serving negotiated responses from cache: header-specific canonicalization" o : "Effect of CC directives on history lists" + o : "Cache + Extensions can override no-store, etc." + Affected issues: o : Status codes and caching Partly resolved issues: o : "Placement of 13.5.1 and 13.5.2" @@ -1711,23 +1733,20 @@ o : "Clarify entity / representation / variant terminology" o : "consider removing the 'changes from 2068' sections" o : "Allowing heuristic caching for new status codes" - o : "Allowing - heuristic caching for new status codes" - o Clean up TODOs and prose in "Combining Responses." C.13. Since draft-ietf-httpbis-p6-cache-11 Closed issues: o : "Text about clock requirement for caches belongs in p6" C.14. Since draft-ietf-httpbis-p6-cache-12 @@ -1740,30 +1759,46 @@ o : "Clarify 'public'" C.15. Since draft-ietf-httpbis-p6-cache-13 Closed issues: o : "untangle ABNFs for header fields" +C.16. Since draft-ietf-httpbis-p6-cache-14 + + Closed issues: + + o : "Mismatch Vary" + o : "Cache + Invalidation only happens upon successful responses" + + o : "Recommend + minimum sizes for protocol elements" + + o : "Proxies don't + 'understand' methods" + + o : "Pragma" + Index A age 6 Age header field 18 C cache 5 Cache Directives - max-age 19, 23 + max-age 20, 23 max-stale 20 min-fresh 20 must-revalidate 22 no-cache 19, 21 no-store 19, 22 no-transform 20, 23 only-if-cached 20 private 21 proxy-revalidate 23 public 21 @@ -1780,46 +1815,46 @@ fresh 6 freshness lifetime 6 G Grammar Age 18 Cache-Control 19 cache-extension 19 cache-request-directive 19 cache-response-directive 21 - delta-seconds 18 + delta-seconds 8 Expires 25 extension-pragma 25 Pragma 25 pragma-directive 25 Vary 26 warn-agent 27 warn-code 27 warn-date 27 warn-text 27 Warning 27 warning-value 27 H Header Fields Age 18 Cache-Control 18 Expires 24 Pragma 25 Vary 26 - Warning 26 + Warning 27 heuristic expiration time 6 M max-age - Cache Directive 19, 23 + Cache Directive 20, 23 max-stale Cache Directive 20 min-fresh Cache Directive 20 must-revalidate Cache Directive 22 N no-cache Cache Directive 19, 21 @@ -1846,21 +1881,21 @@ s-maxage Cache Directive 23 shared cache 5 stale 6 V validator 6 Vary header field 26 W - Warning header field 26 + Warning header field 27 Authors' Addresses Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA EMail: fielding@gbiv.com