Individual Submission B. Drees Internet-Draft Metaweb Technologies, Inc. Intended status: Informational June 14, 2010 Expires: December 16, 2010 The maxage-vary-cookie HTTP Cache-Control Extension draft-drees-http-maxage-vary-cookie-00 Abstract The maxage-vary-cookie HTTP response Cache-Control extension allows an origin server to instruct caches to serve a stale response if the Date header field-value received with the response is greater than a specified date-valued request cookie. It can be used to implement a simple view consistency mechanism for read/write applications while extending freshness lifetimes, reducing latency, bandwidth usage, and origin server load in some situations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." 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 December 16, 2010. Copyright Notice Copyright (c) 2010 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 carefully, as they describe your rights and restrictions with respect to this document. Drees Expires December 16, 2010 [Page 1] Internet-Draft maxage-vary-cookie March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 3. The maxage-vary-cookie Cache-Control Extension . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Drees Expires December 16, 2010 [Page 2] Internet-Draft maxage-vary-cookie March 2010 1. Introduction The HTTP [RFC2616] caching model is based on expiration and validation. The model works well for resources that change at predictable intervals, and for client applications that can tolerate resources that are inconsistent with the origin server for limited amounts of time. It works less well for read/write applications that require a resource to be consistent in some, but not all, circumstances. It requires an origin server to choose between performance (long expiration, less frequent validation) and consistency (short expiration, more frequent validation) at the time the response headers for a resource are generated, whereas the best choice may depend on the context of a particular subsequent request. Readers expect rapid responses. Writers expect to "see the results" of their writes immediately. Servers and clients comprising these applications often suppress caching aggressively, forgoing quick responses to readers in order to guarantee consistent responses to writers. This increases latency, bandwidth usage, and origin server load unnecessarily in many cases. The maxage-vary-cookie HTTP Cache-Control extension addresses this problem by allowing the choice between performance and consistency to be made by a cache in the context of a particular request, in a way that is controlled by the origin server. It instructs a cache to extend the freshness lifetime of a response if its Date is greater than a specified date-valued request cookie [RFC1123], [RFC2965]. 2. Notational Conventions 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 uses the augmented Backus-Naur Form of RFC2616 [RFC2616], and includes the delta-seconds and token rules from that specification. Drees Expires December 16, 2010 [Page 3] Internet-Draft maxage-vary-cookie March 2010 3. The maxage-vary-cookie Cache-Control Extension The maxage-vary-cookie Cache-Control extension indicates that shared and private caches MAY serve a cached response after it becomes stale, up to the indicated number of seconds, unless the request includes a cookie [RFC2965] with the indicated name and a date value [RFC1123] greater than or equal to the response Date. maxage-vary-cookie = "maxage-vary-cookie" "=" <"> delta-seconds "|" cookie-name <"> cookie-name = token A cache MUST NOT serve a stale response due to the presence of this extension if doing so is explicitly disallowed by any RFC 2616 [RFC2616] request header (e.g., Cache-Control: max-age=0). A cache MUST NOT fetch a fresh response due to the presence of this extension if doing so is explicitly discouraged by any RFC 2616 [RFC2616] request header (e.g., Cache-Control: max-stale=86400). Note that this extension involves comparing two absolute dates. Both date values are set from within the same domain. Server administrators are presumed to exercise sufficient control over clock synchronization at the origin servers to avoid problems. 4. Examples An origin server would assign a short expiration to a response via Expires and/or Cache-Control: max-age (typically 0) to make Cache-Control: maxage-vary-cookie work as intended (just as it would to choose consistency over performance if maxage-vary-cookie were not available). It would then set or update the specified cookie value to "the current time" when any subsequent request (one with write semantics, for example) has the effect of decreasing the client's tolerance for inconsistency. A cached response Date less than or equal to the cookie value indicates possible inconsistency, resulting in a cache miss. A cached response Date greater than the cookie value, or the absence of the cookie, on the other hand, indicates there is no risk of perceived inconsistency, resulting in a cache hit. Drees Expires December 16, 2010 [Page 4] Internet-Draft maxage-vary-cookie March 2010 A response containing: HTTP/1.1 200 OK Date: Fri, 14 Dec 2007 23:20:18 GMT Cache-Control: max-age=0, maxage-vary-cookie="3600|LastWriteTime" indicates that it is fresh for 0 seconds, and that it may be used to satisfy requests for an additional 3600 seconds unless the request includes a cookie named "LastWriteTime" with a date value greater than or equal to "Fri, 14 Dec 2007 23:20:18 GMT" (date comparison, not lexical comparison). A request without a matching cookie or with a matching cookie that cannot be interpreted as a date would receive this response for 3600 seconds. A request containing: Cookie: LastWriteTime="Fri, 12 Dec 2007 07:29:36 GMT" would receive this response for 3600 seconds since the cookie date is less than the response Date. A request containing: Cookie: LastWriteTime="Fri, 14 Dec 2007 23:30:01 GMT" would trigger a refresh since the cookie date is greater than the response Date. A request containing: Cookie: LastWriteTime="Fri, 14 Dec 2007 23:20:18 GMT" would also trigger a refresh since the cookie date is equal to the response Date. The same rules apply to conditional requests if such requests are enabled by a Last-Modified or ETag validator in the response. Note that even though response hit/miss status depends on a cookie, the responses need not be marked "Vary: Cookie". The cookie is not part of the cache key - it only affects the freshness calculation. Drees Expires December 16, 2010 [Page 5] Internet-Draft maxage-vary-cookie March 2010 5. Security Considerations This mechanism does not have any security-specific concerns. 6. IANA Considerations This document has no actions for IANA. 7. Normative References [RFC1123] Braden, R., "Requirements for Internet Hosts - application and support", STD 3, RFC 1123, January 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000. Appendix A. Acknowledgements Thanks to John Plevyak and Nick Thompson for their suggestions. The author takes all responsibility for errors and omissions. Authors' Address Ben Drees Metaweb Technologies, Inc. 631 Howard Street, Suite 400 San Francisco, CA 94105 United States Phone: +1 415 546 2000 Email: ben@metaweb.com Drees Expires December 16, 2010 [Page 6]