idnits 2.17.00 (12 Aug 2021) /tmp/idnits20216/draft-ietf-httpbis-immutable-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 1776 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group P. McManus 3 Internet-Draft Mozilla 4 Intended status: Standards Track July 3, 2017 5 Expires: January 4, 2018 7 HTTP Immutable Responses 8 draft-ietf-httpbis-immutable-03 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 Note to Readers 19 Discussion of this draft takes place on the HTTP working group 20 mailing list (ietf-http-wg@w3.org), which is archived at 21 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 23 Working Group information can be found at http://httpwg.github.io/ ; 24 source code and issues list for this draft can be found at 25 https://github.com/httpwg/http-extensions/labels/immutable . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 4, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 HTTP's freshness lifetime mechanism [RFC7234] allows a client to 62 safely reuse a stored response to satisfy future requests for a 63 specified period of time. However, it is still possible that the 64 resource will be modified during that period. 66 For instance, a front page newspaper photo with a freshness lifetime 67 of one hour would mean that no user would see a cached photo more 68 than one hour old. However, the photo could be updated at any time 69 resulting in different users seeing different photos depending on the 70 contents of their caches for up to one hour. This is compliant with 71 the caching mechanism defined in [RFC7234]. 73 Users that need to confirm there have been no updates to their cached 74 responses typically use the reload (or refresh) mechanism in their 75 user agents. This in turn generates a conditional request [RFC7232] 76 and either a new representation or, if unmodified, a 304 (Not 77 Modified) response [RFC7232] is returned. A user agent that 78 understands HTML and fetches its dependent sub-resources might issue 79 hundreds of conditional requests to refresh all portions of a common 80 page [REQPERPAGE]. 82 However some content providers never create more than one variant of 83 a sub-resource, because they use "versioned" URLs. When these 84 resources need an update they are simply published under a new URL, 85 typically embedding an identifier unique to that version of the 86 resource in the path, and references to the sub-resource are updated 87 with the new path information. 89 For example, "https://www.example.com/101016/main.css" might be 90 updated and republished as "https://www.example.com/102026/main.css", 91 with any links that reference it being changed at the same time. 92 This design pattern allows a very large freshness lifetime to be used 93 for the sub-resource without guessing when it will be updated in the 94 future. 96 Unfortunately, the user agent does not know when this versioned URL 97 design pattern is used. As a result, user-driven refreshes still 98 translate into wasted conditional requests for each sub-resource as 99 each will return 304 responses. 101 The "immutable" HTTP response Cache-Control extension allows servers 102 to identify responses that will not be updated during their freshness 103 lifetimes. 105 This effectively informs clients that any conditional request for 106 that response can be safely skipped without worrying that it has been 107 updated. 109 1.1. Notational Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. The immutable Cache-Control extension 117 When present in an HTTP response, the "immutable" Cache-Control 118 extension indicates that the origin server will not update the 119 representation of that resource during the freshness lifetime of the 120 response. 122 Clients SHOULD NOT issue a conditional request during the response's 123 freshness lifetime (e.g. upon a reload) unless explicitly overridden 124 by the user (e.g. a force reload). 126 The immutable extension only applies during the freshness lifetime of 127 the stored response. Stale responses SHOULD be revalidated as they 128 normally would be in the absence of immutable. 130 The immutable extension takes no arguments. If any arguments are 131 present, they have no meaning, and MUST be ignored. Multiple 132 instances of the immutable extension are equivalent to one instance. 133 The presence of an immutable Cache-Control extension in a request has 134 no effect. 136 2.1. About Intermediaries 138 An immutable response has the same semantic meaning when received by 139 proxy clients as it does when received by User-Agent based clients. 140 Therefore proxies SHOULD skip conditionally revalidating fresh 141 responses containing the immutable extension unless there is a signal 142 from the client that a validation is necessary (e.g. a no-cache 143 Cache-Control request directive defined by Section 5.2.1.4 of 144 [RFC7234]). 146 A proxy that uses immutable to bypass a conditional revalidation can 147 choose whether to reply with a 304 or 200 to its requesting client 148 based on the request headers the proxy received. 150 2.2. Example 152 Cache-Control: max-age=31536000, immutable 154 3. Security Considerations 156 The immutable mechanism acts as form of soft pinning and, as with all 157 pinning mechanisms, creates a vector for amplification of cache 158 corruption incidents. These incidents include cache poisoning 159 attacks. Three mechanisms are suggested for mitigation of this risk: 161 o Clients SHOULD ignore immutable from resources that are not part 162 of an authenticated context such as HTTPS. Authenticated 163 resources are less vulnerable to cache poisoning. 165 o User-Agents often provide two different refresh mechanisms: reload 166 and some form of force-reload. The latter is used to rectify 167 interrupted loads and other corruption. These reloads, typically 168 indicated through no-cache request attributes, SHOULD ignore 169 immutable as well. 171 o Clients SHOULD ignore immutable for resources that do not provide 172 a strong indication that the stored response size is the correct 173 response size such as responses delimited by connection close. 175 4. IANA Considerations 177 Section 7.1 of [RFC7234] requires registration of the immutable 178 extension in the "Hypertext Transfer Protocol (HTTP) Cache Directive 179 Registry" with IETF Review. 181 o Cache-Directive: immutable 183 o Pointer to specification text: [this document] 185 5. Acknowledgments 187 Thank you to Ben Maurer for partnership in developing and testing 188 this idea. Thank you to Amos Jeffries for help with proxy 189 interactions and to Mark Nottingham for help with the documentation. 191 6. References 193 6.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, 198 . 200 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 201 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 202 DOI 10.17487/RFC7232, June 2014, 203 . 205 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 206 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 207 RFC 7234, DOI 10.17487/RFC7234, June 2014, 208 . 210 6.2. Informative References 212 [REQPERPAGE] 213 "HTTP Archive", n.d., 214 . 216 Author's Address 218 Patrick McManus 219 Mozilla 221 Email: pmcmanus@mozilla.com