--- 1/draft-ietf-httpbis-p6-cache-04.txt 2008-11-17 16:12:12.000000000 +0100 +++ 2/draft-ietf-httpbis-p6-cache-05.txt 2008-11-17 16:12:12.000000000 +0100 @@ -1,33 +1,33 @@ Network Working Group R. Fielding, Ed. Internet-Draft Day Software Obsoletes: 2616 (if approved) J. Gettys Intended status: Standards Track One Laptop per Child -Expires: March 2, 2009 J. Mogul +Expires: May 20, 2009 J. Mogul HP H. Frystyk Microsoft L. Masinter Adobe Systems P. Leach Microsoft T. Berners-Lee W3C/MIT Y. Lafon, Ed. W3C J. Reschke, Ed. greenbytes - August 29, 2008 + November 16, 2008 HTTP/1.1, part 6: Caching - draft-ietf-httpbis-p6-cache-04 + draft-ietf-httpbis-p6-cache-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -38,42 +38,42 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 2, 2009. + This Internet-Draft will expire on May 20, 2009. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. Editorial Note (To be removed by RFC Editor) Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues list is - at and related + at and related documents (including fancy diffs) can be found at - . + . - The changes in this draft are summarized in Appendix B.4. + The changes in this draft are summarized in Appendix B.6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 2. Notational Conventions and Generic Grammar . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Cache Correctness . . . . . . . . . . . . . . . . . . . . 8 @@ -126,21 +126,22 @@ Appendix A. Compatibility with Previous Versions . . . . . . . . 44 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45 Appendix B. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 45 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 45 B.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 45 B.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 46 B.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 46 B.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 46 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 47 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 52 1. Introduction HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches, and includes a number of elements intended to make caching work as well as possible. Because these elements interact with each other, it is useful to describe the caching design of HTTP separately. This @@ -279,37 +280,36 @@ REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." 2. Notational Conventions and Generic Grammar This specification uses the ABNF syntax defined in Section 2.1 of [Part1] and the core rules defined in Section 2.2 of [Part1]: - [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC - 5234, see .]] DIGIT = DQUOTE = SP = quoted-string = token = + OWS = The ABNF rules below are defined in other parts: field-name = HTTP-date = - port = + port = pseudonym = - uri-host = + uri-host = 3. Overview 3.1. Cache Correctness A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see Sections 4.5, 4.6, and 14) which meets one of the following conditions: @@ -1177,89 +1177,90 @@ This section defines the syntax and semantics of HTTP/1.1 header fields related to caching. For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity. 16.1. Age - The Age response-header field conveys the sender's estimate of the + The response-header field "Age" conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. Age values are calculated as specified in Section 4.3. - Age = "Age" ":" age-value - age-value = delta-seconds + Age = "Age" ":" OWS Age-v + Age-v = delta-seconds Age values are non-negative decimal integers, representing time in seconds. delta-seconds = 1*DIGIT If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, it MUST transmit an Age header with a value of 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST include an Age header field in every response generated from its own cache. Caches SHOULD use an arithmetic type of at least 31 bits of range. 16.2. Cache-Control - The Cache-Control general-header field is used to specify directives - that MUST be obeyed by all caching mechanisms along the request/ - response chain. The directives specify behavior intended to prevent - caches from adversely interfering with the request or response. - These directives typically override the default caching algorithms. - Cache directives are unidirectional in that the presence of a - directive in a request does not imply that the same directive is to - be given in the response. + The general-header field "Cache-Control" is used to specify + directives that MUST be obeyed by all caching mechanisms along the + request/response chain. The directives specify behavior intended to + prevent caches from adversely interfering with the request or + response. These directives typically override the default caching + algorithms. Cache directives are unidirectional in that the presence + of a directive in a request does not imply that the same directive is + to be given in the response. Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see Section 16.4). Cache directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to specify a cache- directive for a specific cache. - Cache-Control = "Cache-Control" ":" 1#cache-directive + Cache-Control = "Cache-Control" ":" OWS Cache-Control-v + Cache-Control-v = 1#cache-directive cache-directive = cache-request-directive - | cache-response-directive + / cache-response-directive cache-request-directive = "no-cache" ; Section 16.2.1 - | "no-store" ; Section 16.2.2 - | "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4 - | "max-stale" [ "=" delta-seconds ] ; Section 16.2.3 - | "min-fresh" "=" delta-seconds ; Section 16.2.3 - | "no-transform" ; Section 16.2.5 - | "only-if-cached" ; Section 16.2.4 - | cache-extension ; Section 16.2.6 + / "no-store" ; Section 16.2.2 + / "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4 + / "max-stale" [ "=" delta-seconds ] ; Section 16.2.3 + / "min-fresh" "=" delta-seconds ; Section 16.2.3 + / "no-transform" ; Section 16.2.5 + / "only-if-cached" ; Section 16.2.4 + / cache-extension ; Section 16.2.6 cache-response-directive = "public" ; Section 16.2.1 - | "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1 - | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1 - | "no-store" ; Section 16.2.2 - | "no-transform" ; Section 16.2.5 - | "must-revalidate" ; Section 16.2.4 - | "proxy-revalidate" ; Section 16.2.4 - | "max-age" "=" delta-seconds ; Section 16.2.3 - | "s-maxage" "=" delta-seconds ; Section 16.2.3 - | cache-extension ; Section 16.2.6 + / "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1 + / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1 + / "no-store" ; Section 16.2.2 + / "no-transform" ; Section 16.2.5 + / "must-revalidate" ; Section 16.2.4 + / "proxy-revalidate" ; Section 16.2.4 + / "max-age" "=" delta-seconds ; Section 16.2.3 + / "s-maxage" "=" delta-seconds ; Section 16.2.3 + / cache-extension ; Section 16.2.6 - cache-extension = token [ "=" ( token | quoted-string ) ] + cache-extension = token [ "=" ( token / quoted-string ) ] When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply these directives to header fields not defined in HTTP/1.1. The cache-control directives can be broken down into these general @@ -1663,21 +1664,22 @@ intermediate cache that has a fresh copy of the entity). See Section 4 for further discussion of the expiration 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 format is an absolute date and time as defined by HTTP-date in Section 3.3.1 of [Part1]; it MUST be sent in rfc1123-date format. - Expires = "Expires" ":" HTTP-date + Expires = "Expires" ":" OWS Expires-v + Expires-v = HTTP-date An example of its use is Expires: Thu, 01 Dec 1994 16:00:00 GMT Note: if a response includes a Cache-Control field with the max- age directive (see Section 16.2.3), that directive overrides the Expires field. HTTP/1.1 clients and caches MUST treat other invalid date formats, @@ -1693,29 +1695,30 @@ sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field (Section 16.2). 16.4. Pragma - The Pragma general-header field is used to include implementation- + The general-header field "Pragma" is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. - Pragma = "Pragma" ":" 1#pragma-directive - pragma-directive = "no-cache" | extension-pragma - extension-pragma = token [ "=" ( token | quoted-string ) ] + Pragma = "Pragma" ":" OWS Pragma-v + Pragma-v = 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, an application SHOULD forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive has the same semantics as the no-cache cache-directive (see Section 16.2) and is defined here for backward compatibility with HTTP/1.0. Clients SHOULD include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. Pragma directives MUST be passed through by a proxy or gateway @@ -1728,32 +1731,33 @@ HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in HTTP. Note: because the meaning of "Pragma: no-cache" as a response- header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response. 16.5. Vary - The Vary response-header field's value indicates the set of request- - header fields that fully determines, while the response is fresh, - whether a cache is permitted to use the response to reply to a + The "Vary" response-header field's value indicates the set of + request-header fields that fully determines, while the response is + fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. See Section 8 for use of the Vary header field by caches. - Vary = "Vary" ":" ( "*" | 1#field-name ) + Vary = "Vary" ":" OWS Vary-v + Vary-v = "*" / 1#field-name An HTTP/1.1 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. @@ -1771,36 +1775,37 @@ insensitive. A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address of the client), play a role in the selection of the response representation. The "*" value MUST NOT be generated by a proxy server; it may only be generated by an origin server. 16.6. Warning - The Warning general-header field is used to carry additional + The general-header field "Warning" is used to carry additional information about the status or transformation of a message which might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message. Warning headers are sent with responses using: - Warning = "Warning" ":" 1#warning-value + Warning = "Warning" ":" OWS Warning-v + Warning-v = 1#warning-value warning-value = warn-code SP warn-agent SP warn-text [SP warn-date] warn-code = 3DIGIT - warn-agent = ( uri-host [ ":" port ] ) | pseudonym + warn-agent = ( uri-host [ ":" port ] ) / pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string warn-date = DQUOTE HTTP-date DQUOTE A response MAY carry more than one Warning header. The warn-text SHOULD be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. This decision MAY be based on any available knowledge, @@ -1945,52 +1950,52 @@ [ISO-8859-1] International Organization for Standardization, "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO/ IEC 8859-1:1998, 1998. [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-04 - (work in progress), August 2008. + and Message Parsing", draft-ietf-httpbis-p1-messaging-05 + (work in progress), November 2008. [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-04 (work in - progress), August 2008. + Semantics", draft-ietf-httpbis-p2-semantics-05 (work in + progress), November 2008. [Part3] 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 3: Message Payload - and Content Negotiation", draft-ietf-httpbis-p3-payload-04 - (work in progress), August 2008. + and Content Negotiation", draft-ietf-httpbis-p3-payload-05 + (work in progress), November 2008. [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-04 (work in - progress), August 2008. + Requests", draft-ietf-httpbis-p4-conditional-05 (work in + progress), November 2008. [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-04 (work - in progress), August 2008. + Partial Responses", draft-ietf-httpbis-p5-range-05 (work + in progress), November 2008. [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-04 (work in progress), - August 2008. + draft-ietf-httpbis-p7-auth-05 (work in progress), + November 2008. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 20.2. Informative References @@ -2041,88 +2045,101 @@ Appendix B. Change Log (to be removed by RFC Editor before publication) B.1. Since RFC2616 Extracted relevant partitions from [RFC2616]. B.2. Since draft-ietf-httpbis-p6-cache-00 Closed issues: - o : "Trailer" + o : "Trailer" () - o : - "Invalidation after Update or Delete" + o : "Invalidation + after Update or Delete" () - o : "Normative - and Informative references" + o : "Normative and + Informative references" - o : "Date - reference typo" + o : "Date reference + typo" - o : - "Connection header text" + o : "Connection + header text" - o : - "Informative references" + o : "Informative + references" + o : "ISO-8859-1 + Reference" - o : - "ISO-8859-1 Reference" - o : "Normative - up-to-date references" + o : "Normative up- + to-date references" - o : "typo in + o : "typo in 13.2.2" Other changes: o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress - on ) + on ) B.3. Since draft-ietf-httpbis-p6-cache-01 Closed issues: - o : "rel_path - not used" + o : "rel_path not + used" Other changes: o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work - in progress on - ) + in progress on ) o Add explicit references to BNF syntax and rules imported from other parts of the specification. B.4. Since draft-ietf-httpbis-p6-cache-02 Ongoing work on IANA Message Header Registration - (): + (): o Reference RFC 3984, and update header registrations for headers defined in this document. B.5. Since draft-ietf-httpbis-p6-cache-03 Closed issues: - o : "Vary - header classification" + o : "Vary header + classification" + +B.6. Since draft-ietf-httpbis-p6-cache-04 + + Ongoing work on ABNF conversion + (): + + o Use "/" instead of "|" for alternatives. + + o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional + whitespace ("OWS") and required whitespace ("RWS"). + + o Rewrite ABNFs to spell out whitespace rules, factor out header + value format definitions. Index A age 7 Age header 27 + C cache 5 Cache Directives max-age 32-33 max-stale 32 min-fresh 32 must-revalidate 34 no-cache 29 no-store 30 no-transform 35 @@ -2139,38 +2156,44 @@ explicit expiration time 7 F first-hand 6 fresh 7 freshness lifetime 7 G Grammar Age 27 - age-value 27 + Age-v 27 Cache-Control 28 + Cache-Control-v 28 cache-directive 28 cache-extension 28 cache-request-directive 28 cache-response-directive 28 delta-seconds 27 Expires 37 + Expires-v 37 extension-pragma 38 Pragma 38 pragma-directive 38 - Vary 38 + Pragma-v 38 + Vary 39 + Vary-v 39 warn-agent 40 warn-code 40 warn-date 40 warn-text 40 Warning 40 + Warning-v 40 warning-value 40 + H Headers Age 27 Cache-Control 27 Expires 37 Pragma 38 Vary 38 Warning 39 heuristic expiration time 7