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