idnits 2.17.1 draft-mcmanus-immutable-01.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...' RFC 2119 keyword, line 114: '...ed clients and they therefore MAY also...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2016) is 2657 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 December 19, 2016 5 Expires: June 22, 2017 7 HTTP Immutable Responses 8 draft-mcmanus-immutable-01 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 June 22, 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://www.example.com/102026/main.css and the 80 html that references it is changed at the same time. This design 81 pattern allows a very large freshness lifetime to be applied to the 82 sub-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. About Intermediaries 113 An immutable response has the same semantic meaning for proxy clients 114 as it does for User-Agent based clients and they therefore MAY also 115 presume a conditional revalidation for a response marked immutable 116 would return 304. A proxy client who uses immutable to anticipate a 117 304 response may choose whether to reply with a 304 or 200 to its 118 requesting client. 120 2.2. Example 122 Cache-Control: max-age=31536000, immutable 124 3. Security Considerations 126 The immutable mechanism acts as form of soft pinning and, as with all 127 pinning mechanisms, creates a vector for amplification of cache 128 corruption incidents. These incidents include cache poisoning 129 attacks. Three mechanisms are suggested for mitigation of this risk: 131 o Clients should ignore immutable for resources that are not part of 132 an authenticated context such as HTTPS. Authenticated resources 133 are less vulnerable to cache poisoning. 135 o User-Agents often provide two different refresh mechanismss: 136 reload and some form of force-reload. The latter is used to 137 rectify interrupted loads and other corruption. These reloads, 138 typically indicated through no-cache request attributes, should 139 ignore immutable as well. 141 o Clients should ignore immutable for resources that do not provide 142 a strong indication that the stored response size is the correct 143 response size such as responses delimited by connection close. 145 4. IANA Considerations 147 [RFC7234] sections 7.1 and 7.1.2 require registration of the 148 immutable extension in the "Hypertext Transfer Protocol (HTTP) Cache 149 Directive Registry" with IETF Review. 151 o Cache-Directive: immutable 153 o Pointer to specification text: [this document] 155 5. Acknowledgments 157 Thank you to Ben Maurer for partnership in developing and testing 158 this idea. Thank you to Amos Jeffries for help with proxy 159 interactions. 161 6. References 163 6.1. Normative References 165 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 166 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 167 DOI 10.17487/RFC7231, June 2014, 168 . 170 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 171 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 172 DOI 10.17487/RFC7232, June 2014, 173 . 175 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 176 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 177 RFC 7234, DOI 10.17487/RFC7234, June 2014, 178 . 180 6.2. Informative References 182 [REQPERPAGE] 183 "HTTP Archive", n.d., 184 . 186 Author's Address 188 Patrick McManus 189 Mozilla 191 Email: pmcmanus@mozilla.com