idnits 2.17.1 draft-ietf-httpbis-immutable-02.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 116: '... Clients SHOULD NOT issue a conditio...' RFC 2119 keyword, line 121: '... Stale responses SHOULD be revalidated...' RFC 2119 keyword, line 125: '... no meaning, and MUST be ignored. Mul...' RFC 2119 keyword, line 134: '...herefore proxies SHOULD skip condition...' RFC 2119 keyword, line 154: '... o Clients SHOULD ignore immutable ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2017) is 2546 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) == Unused Reference: 'RFC7231' is defined on line 188, but no explicit reference was found in the text ** 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP P. McManus 3 Internet-Draft Mozilla 4 Intended status: Standards Track April 30, 2017 5 Expires: November 1, 2017 7 HTTP Immutable Responses 8 draft-ietf-httpbis-immutable-02 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 November 1, 2017. 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 2. The immutable Cache-Control extension 111 When present in an HTTP response, the "immutable" Cache-Control 112 extension indicates that the origin server will not update the 113 representation of that resource during the freshness lifetime of the 114 response. 116 Clients SHOULD NOT issue a conditional request during the response's 117 freshness lifetime (e.g. upon a reload) unless explicitly overridden 118 by the user (e.g. a force reload). 120 The immutable extension only applies during the freshness lifetime of 121 the stored response. Stale responses SHOULD be revalidated as they 122 normally would be in the absence of immutable. 124 The immutable extension takes no arguments. If any arguments are 125 present, they have no meaning, and MUST be ignored. Multiple 126 instances of the immutable extension are equivalent to one instance. 127 The presence of an immutable Cache-Control extension in a request has 128 no effect. 130 2.1. About Intermediaries 132 An immutable response has the same semantic meaning when received by 133 proxy clients as it does when received by User-Agent based clients. 134 Therefore proxies SHOULD skip conditionally revalidating fresh 135 responses containing the immutable extension unless there is a signal 136 from the client that a validation is necessary (e.g. a no-cache 137 Cache-Control request directive). 139 A proxy that uses immutable to bypass a conditional revalidation may 140 choose whether to reply with a 304 or 200 to its requesting client 141 based on the request headers the proxy received. 143 2.2. Example 145 Cache-Control: max-age=31536000, immutable 147 3. Security Considerations 149 The immutable mechanism acts as form of soft pinning and, as with all 150 pinning mechanisms, creates a vector for amplification of cache 151 corruption incidents. These incidents include cache poisoning 152 attacks. Three mechanisms are suggested for mitigation of this risk: 154 o Clients SHOULD ignore immutable from resources that are not part 155 of an authenticated context such as HTTPS. Authenticated 156 resources are less vulnerable to cache poisoning. 158 o User-Agents often provide two different refresh mechanisms: reload 159 and some form of force-reload. The latter is used to rectify 160 interrupted loads and other corruption. These reloads, typically 161 indicated through no-cache request attributes, SHOULD ignore 162 immutable as well. 164 o Clients SHOULD ignore immutable for resources that do not provide 165 a strong indication that the stored response size is the correct 166 response size such as responses delimited by connection close. 168 4. IANA Considerations 170 [RFC7234] sections 7.1 and 7.1.2 require registration of the 171 immutable extension in the "Hypertext Transfer Protocol (HTTP) Cache 172 Directive Registry" with IETF Review. 174 o Cache-Directive: immutable 176 o Pointer to specification text: [this document] 178 5. Acknowledgments 180 Thank you to Ben Maurer for partnership in developing and testing 181 this idea. Thank you to Amos Jeffries for help with proxy 182 interactions and to Mark Nottingham for help with the documentation. 184 6. References 186 6.1. Normative References 188 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 189 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 190 DOI 10.17487/RFC7231, June 2014, 191 . 193 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 194 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 195 DOI 10.17487/RFC7232, June 2014, 196 . 198 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 199 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 200 RFC 7234, DOI 10.17487/RFC7234, June 2014, 201 . 203 6.2. Informative References 205 [REQPERPAGE] 206 "HTTP Archive", n.d., 207 . 209 Author's Address 211 Patrick McManus 212 Mozilla 214 Email: pmcmanus@mozilla.com