



Network Working Group                                      M. Nottingham
Internet-Draft
Intended status: Informational                                  M. Kelly
Expires: January 23, 2020                                  July 22, 2017


                       Linked Cache Invalidation
                  draft-nottingham-linked-cache-inv-05

Abstract

   This memo defines two new link types that indicate relationships
   between resources in terms of cache invalidation, along with a HTTP
   cache-control extension that takes advantage of those relationships
   to use them to extend response freshness.  Collectively, this is
   referred to as Linked Cache Invalidation (LCI).

Note to Readers

   The issues list for this draft can be found at
   https://github.com/mnot/I-D/labels/linked-cache-inv [1].

   The most recent (often, unpublished) draft is at
   https://mnot.github.io/I-D/linked-cache-inv/ [2].

   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
   pages/linked-cache-inv [3].

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 https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 23, 2020.







Nottingham & Kelly      Expires January 23, 2020                [Page 1]

Internet-Draft          Linked Cache Invalidation              July 2017


Copyright Notice

   Copyright (c) 2017 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
   (https://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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
   2.  The 'invalidates' Link Relation Type  . . . . . . . . . . . .   5
   3.  The 'inv-by' Link Relation Type . . . . . . . . . . . . . . .   5
   4.  The 'inv-maxage' Response Cache-Control Extension . . . . . .   6
     4.1.  inv-maxage Syntax . . . . . . . . . . . . . . . . . . . .   6
     4.2.  inv-maxage Semantics  . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
     7.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   In normal operation, a HTTP [RFC7230] cache will invalidate a stored
   response if an unsafe request (e.g., POST, PUT or DELETE) is made to
   its URI.  HTTP also provides for such a state-changing request to
   invalidate related resources (using the Location and Content-Location
   headers in the response), but this is of limited utility, because
   those headers have defined semantics, and can only occur once each.

   Because of this, it is not practical to make a response that depends
   on the state of another resource cacheable.  For example, an update
   to a blog entry might change several different resources, such as the
   user's summary page, the blog's "front" page, the blog's Atom feed,
   and of course the blog entry itself.  If any of these resources is



Nottingham & Kelly      Expires January 23, 2020                [Page 2]

Internet-Draft          Linked Cache Invalidation              July 2017


   made cacheable, it will not reflect those changes, causing confusion
   if the user tries to verify that their changes have been correctly
   applied.

   This memo introduces new link relation types
   [I-D.nottingham-rfc5988bis] that allow more fine-grained
   relationships between resources to be defined, so that caches can
   invalidate all related representations when the state of one changes.
   It also introduces a cache-control response extension, so that
   responses using the relations can be cached by implementations that
   understand these relations.

1.1.  Example

   Taking the blog use case described above, imagine that we have the
   following related resources:

   o  http://example.com/blog/2012/05/04/hi [the blog entry]

   o  http://example.com/blog/2012/05/04/hi/comments [full comments for
      the entry]

   o  http://example.com/blog/ {the blog "home"}

   o  http://example.com/users/bob/ [the user page, listing his entries]

   When someone comments on Bob's blog entry, they might send a request
   like this:

   POST /cgi-bin/blog.cgi HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 7890

   [...]

   When the comment is successful, it's typical to redirect the client
   back to the original blog page, with a response like this:

   HTTP/1.1 302 Moved Temporarily
   Location: http://example.com/blog/2012/05/04/hi
   Content-Length: 0


   Which would invalidate the blog entry URI, as per HTTP's normal
   operation.





Nottingham & Kelly      Expires January 23, 2020                [Page 3]

Internet-Draft          Linked Cache Invalidation              July 2017


   To invalidate the full comments page for the entry, the relationship
   can be described in that page's response headers:

   HTTP/1.1 200 OK
   Content-Type: text/html
   Content-Length: 5555
   Link: </blog/2012/05/04/hi>; rel="inv-by"
   Cache-Control: no-cache, inv-maxage=600

   [...]

   This declares that whenever the entry page (the target of the link
   header) changes, this response (the full comments page) changes as
   well; it's invalidated by the link target.

   Note that the full comments page also carries a Cache-Control header
   that instructs "normal" caches not to reuse this response, but allows
   those caches that are aware of LCI to consider it fresh for ten
   minutes.

   To invalidate the blog home page and user page, it's impractical to
   list all of the resources that might change if a new entry is posted;
   not only are there many of them, but their URLs might not be known
   when the pages are cached.  To address this, the POST response itself
   (i.e., when the comment is made) can nominate resources to
   invalidate, using the 'invalidates' relation, making that response:

   HTTP/1.1 302 Moved Temporarily
   Location: http://example.com/blog/2012/05/04/hi
   Link: <http://example.com/blog/>; rel="invalidates",
         <http://example.com/users/bob/>; rel="invalidates"
   Content-Length: 0


   Depending on how important it is to see updates on the home page and
   user page, those responses can either allow caching regardless of
   support for LCI, like this:

   Cache-Control: max-age=300

   ... or they can only allow caching by LCI-aware caches, like this:

   Cache-Control: no-cache, inv-maxage=300

   Together, these techniques can be used to invalidate a variety of
   related responses.





Nottingham & Kelly      Expires January 23, 2020                [Page 4]

Internet-Draft          Linked Cache Invalidation              July 2017


   It is important to note that the invalidations are only effective in
   the caches that the client's request stream travels through.  This
   means other caches will continue to serve the "old" content until the
   invalidation event is propagated to them (see below) or the cached
   responses become stale.

   When multiple caches are close together, the HyperText Caching
   Protocol (HTCP) [RFC2756] can be used to propagate invalidation
   events between them.

1.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 document uses the Augmented Backus-Naur Form (ABNF) notation of
   [RFC7230], and explicitly includes the following rules from it:
   delta-seconds.

2.  The 'invalidates' Link Relation Type

   The 'invalidates' link relation type allows a response that signifies
   a state change on the server to indicate one or more associated URIs
   whose states have also changed.

   o  Relation name: invalidates

   o  Description: Indicates that when the link context changes, the
      link target also has changed.

   o  Reference: [this document]

   o  Notes:

3.  The 'inv-by' Link Relation Type

   The 'inv-by' link relation type allows a response to nominate one or
   more other resources that affect the state of the resource it's
   associated with.  That is, when one of the nominated resources
   changes, it also changes the state of this response's resource.

   o  Relation name: inv-by

   o  Description: Indicates that when the link target changes, the
      link's context has also changed.

   o  Reference: [this document]



Nottingham & Kelly      Expires January 23, 2020                [Page 5]

Internet-Draft          Linked Cache Invalidation              July 2017


   o  Notes:

4.  The 'inv-maxage' Response Cache-Control Extension

   When present, the 'inv-maxage' cache-control extension indicates the
   number of seconds that caches who implement Linked Cache invalidation
   can consider responses fresh for, provided they are not invalidated.

4.1.  inv-maxage Syntax

   The inv-maxage cache-control extension is parameterised with a
   numeric argument:

   "inv-maxage" "=" ( delta-seconds | ( <"> delta-seconds <"> ) )

   Note that the argument MAY occur in either token or quoted-string
   form.

   If the argument is missing or otherwise does not conform to the BNF
   rule, it is invalid and MUST be ignored by caches.

   If the directive appears more than once in a response, each instance
   is invalid and MUST be ignored by caches.

4.2.  inv-maxage Semantics

   HTTP caches MAY, if they fully implement this specification,
   disregard the HTTP response cache-control directives 'no-cache',
   'max-age' and 's-maxage' when a valid 'inv-maxage' cache-control
   directive is present in a response, using its value as a replacement
   for max-age.

   HTTP caches using inv-maxage to calculate freshness MUST invalidate
   all stored responses whose request-URIs (after normalisation) are the
   target of a 'invalidates' link relation contained in a successful
   response to a state-changing request, provided that they are allowed.

   HTTP caches using inv-maxage to calculate freshness MUST invalidate
   all stored responses containing a 'inv-by' link relation whose target
   is the current request-URI (after normalisation) upon receipt of a
   successful response to a state-changing request.

   Likewise, HTTP caches using inv-maxage to calculate freshness MUST
   invalidate all stored responses containing a 'inv-by' link relation
   whose target is the content of either the Location or Content-
   Location response headers (after normalisation) upon receipt of a
   successful response to a state-changing request.




Nottingham & Kelly      Expires January 23, 2020                [Page 6]

Internet-Draft          Linked Cache Invalidation              July 2017


   Here, a response is considered to "contain" a link relation if it is
   carried in the Link HTTP header [I-D.nottingham-rfc5988bis].  I.e.,
   it is not necessary to look at the response body.

   "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.

   A "successful" response is one with a 2xx or redirecting 3xx (e.g.,
   301, 302, 303, 307) status code.

   A "state-changing" request is one with an unsafe method (e.g., POST,
   PUT, DELETE, PATCH), or one that is not known to be safe.

   In this context, "normalisation" means, in the case of a relative
   request-URI, that it is absolutised using the value of the Host
   request header and the appropriate protocol scheme.

   Finally, an invalidation based upon "invalidates" is "allowed" if the
   host part of the request-URI (if absolute) or Host request header (if
   the request-URI is relative) matches the host part of the target URI.
   This prevents some types of denial-of-service attacks.

   Implementations SHOULD effect invalidations when they become aware of
   changes through other means; e.g., HTCP [RFC2756] CLR messages, upon
   invalidations caused by other links (i.e., chained "cascades" of
   linked invalidations), or when a changed response is seen (such as
   when HTTP validation is unsuccessful).

5.  Security Considerations

   Linked Cache Invalidation does not guarantee that invalidations will
   be effected; e.g., they can be lost due to network issues or cache
   downtime.  Furthermore, it does not guarantee that all caches that
   understand LCI will be made aware of invalidations that happen,
   because of how they originate.

   Therefore, care should be taken that LCI invalidations are not relied
   upon (e.g., to purge sensitive content).

   Furthermore, while some care is taken to avoid denial-of-service
   attacks through invalidation, cache efficiency may still be impaired
   under certain circumstances (e.g., arranging for one request to
   invalidate a large number of responses), leading to a reduction in
   service quality.





Nottingham & Kelly      Expires January 23, 2020                [Page 7]

Internet-Draft          Linked Cache Invalidation              July 2017


6.  IANA Considerations

   This document registers two entries in the Link Relation Type
   Registry; see Section 2 and Section 3.

   It also registers a HTTP Cache Directive, "inv-maxage"; see
   Section 4.

7.  References

7.1.  Normative References

   [I-D.nottingham-rfc5988bis]
              Nottingham, M., "Web Linking", draft-nottingham-
              rfc5988bis-08 (work in progress), August 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

7.2.  Informative References

   [RFC2756]  Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
              (HTCP/0.0)", RFC 2756, DOI 10.17487/RFC2756, January 2000,
              <https://www.rfc-editor.org/info/rfc2756>.

7.3.  URIs

   [1] https://github.com/mnot/I-D/labels/linked-cache-inv

   [2] https://mnot.github.io/I-D/linked-cache-inv/

   [3] https://github.com/mnot/I-D/commits/gh-pages/linked-cache-inv

Appendix A.  Acknowledgements

   Thanks to Michael Hausenblas for his input.








Nottingham & Kelly      Expires January 23, 2020                [Page 8]

Internet-Draft          Linked Cache Invalidation              July 2017


Authors' Addresses

   Mark Nottingham

   Email: mnot@mnot.net
   URI:   https://www.mnot.net/


   Mike Kelly

   Email: mike@stateless.co
   URI:   http://stateless.co







































Nottingham & Kelly      Expires January 23, 2020                [Page 9]
