idnits 2.17.1 draft-mcmanus-immutable-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 98: '... the origin server MUST NOT update the...' RFC 2119 keyword, line 103: '... Stale responses SHOULD be revalidated...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2016) is 2739 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. McManus 3 Internet-Draft Mozilla 4 Intended status: Standards Track October 26, 2016 5 Expires: April 29, 2017 7 HTTP Immutable Responses 8 draft-mcmanus-immutable-00 10 Abstract 12 The immutable HTTP response Cache-Control extension allows servers to 13 identify resources that will not be updated during their freshness 14 lifetime. This assures that a client never needs to revalidate a 15 cached fresh resource to be certain it has not been modified. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 29, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The HTTP freshness lifetime [RFC7234] caching attribute specifies 52 that a client may safely reuse a response to satisfy future requests 53 over a specific period of time. It does not specify that the 54 resource will be not be modified during that period. 56 For instance, a front page newspaper photo with a freshness lifetime 57 of one hour would mean that no user should see a photo more than one 58 hour old. However, the photo could be updated at any time resulting 59 in different users seeing different photos depending on the contents 60 of their caches for up to one hour. This is compliant with the 61 caching mechanism defined in [RFC7234]. 63 Users that need to confirm there have been no updates to their 64 current cached resources typically invoke the reload (or refresh) 65 mechanism in the user agent. This in turn generates a conditional 66 request [RFC7232] and either a new representation or, if unmodified, 67 a 304 response [RFC7231] is returned. A user agent that manages HTML 68 and its dependent sub-resources may issue hundreds of conditional 69 requests to refresh all portions of a common HTML page [REQPERPAGE]. 71 Through the use of the versioned URL design pattern some content 72 providers never create more than one variant of a sub-resource. When 73 these resources need an update they are simply published under a new 74 URL, typically embedding a variant identifier in the path, and 75 references to the sub-resource are updated with the new path 76 information. 78 For example, https://www.example.com/101016/main.css might be updated 79 and republished as https://102026/main.css and the html that 80 references it is changed at the same time. This design pattern 81 allows a very large freshness lifetime to be applied to the sub- 82 resource without guessing when it will be updated in the future. 84 Unfortunately, the user-agent is not aware of the versioned URL 85 design pattern. User driven refresh events still translate into 86 wasted conditional requests for each sub-resource as each will return 87 304 responses. 89 The immutable HTTP response Cache-Control extension allows servers to 90 identify resources that will not be updated during their freshness 91 lifetime. This effectively instructs the client that any conditional 92 request for a previously served variant of that resource may be 93 safely skipped without worrying that it has been updated. 95 2. The immutable Cache-Control extension 97 When present in an HTTP response, the immutable Cache-Control 98 extension indicates that the origin server MUST NOT update the 99 representation of that resource during the freshness lifetime of the 100 response. 102 The immutable extension only applies during the freshness lifetime of 103 the response. Stale responses SHOULD be revalidated as they normally 104 would be in the absence of immutable. 106 The immutable extension takes no arguments and if any arguments are 107 present they have no meaning. Multiple instances of the immutable 108 extension are equivalent to one instance. The presence of an 109 immutable Cache-Control extension in a request has no effect. 111 2.1. Example 113 Cache-Control: max-age=31536000, immutable 115 3. Security Considerations 117 The immutable mechanism acts as form of soft pinning and, as with all 118 pinning mechanisms, creates a vector for the amplification of a cache 119 poisoning attack. Two mechanisms are suggested for mitigation of 120 this risk: 122 o Clients should ignore immutable for resources that are not part of 123 a secure context [SECURECONTEXTS]. Authenticated resources are 124 less vulnerable to cache poisoning. 126 o User-Agents often provide two different refresh mechanisms: reload 127 and some form of force-reload. The latter is used to rectify 128 interrupted loads and other corruption. These reloads should 129 ignore immutable as well. 131 4. IANA Considerations 133 [RFC7234] sections 7.1 and 7.1.2 require registration of the 134 immutable extension in the "Hypertext Transfer Protocol (HTTP) Cache 135 Directive Registry" with IETF Review. 137 o Cache-Directive: immutable 139 o Pointer to specification text: [this document] 141 5. Acknowledgments 143 Thank you to Ben Maurer for partnership in developing and testing 144 this idea. 146 6. References 148 6.1. Normative References 150 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 151 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 152 DOI 10.17487/RFC7231, June 2014, 153 . 155 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 156 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 157 DOI 10.17487/RFC7232, June 2014, 158 . 160 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 161 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 162 RFC 7234, DOI 10.17487/RFC7234, June 2014, 163 . 165 6.2. Informative References 167 [SECURECONTEXTS] 168 West, M., "Secure Contexts", n.d., . 171 [REQPERPAGE] 172 "HTTP Archive", n.d., 173 . 175 Author's Address 177 Patrick McManus 178 Mozilla 180 Email: pmcmanus@mozilla.com