idnits 2.17.1 draft-nottingham-cache-trailers-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 : ---------------------------------------------------------------------------- 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 (8 March 2021) is 1146 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) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-cache' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Standards Track J. Snell 5 Expires: 9 September 2021 8 March 2021 7 Updating HTTP Caching Policy in Trailers 8 draft-nottingham-cache-trailers-00 10 Abstract 12 This specification defines how to update caching policy for a 13 response in HTTP trailer fields, after the content has been sent. 15 Note to Readers 17 _RFC EDITOR: please remove this section before publication_ 19 The issues list for this draft can be found at 20 https://github.com/mnot/I-D/labels/cache-trailers 21 (https://github.com/mnot/I-D/labels/cache-trailers). 23 The most recent (often, unpublished) draft is at 24 https://mnot.github.io/I-D/cache-trailers/ (https://mnot.github.io/I- 25 D/cache-trailers/). 27 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 28 pages/cache-trailers (https://github.com/mnot/I-D/commits/gh-pages/ 29 cache-trailers). 31 See also the draft's current status in the IETF datatracker, at 32 https://datatracker.ietf.org/doc/draft-nottingham-cache-trailers/ 33 (https://datatracker.ietf.org/doc/draft-nottingham-cache-trailers/). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 9 September 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 69 2. The "trailer-update" HTTP Cache Directive . . . . . . . . . . 3 70 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 Web content that is "dynamically" generated -- i.e., with the 79 response body streamed by the server to the client as it is created 80 -- is often assumed to be uncacheable. In practice, though, there 81 are some scenarios where caching is beneficial; for example, when a 82 private cache might be able to reuse a personalised, dynamic response 83 for a period, or when such a response can be shared by a number of 84 clients. 86 A server choosing a caching policy for such a response faces a 87 conundrum: if an error or other unforeseen condition happens during 88 the generation of the response, that caching policy might be too 89 liberal. Currently, the only available solutions are to: 91 1. prevent or severely curtail downstream caching, or 93 2. buffer the response until a caching policy can be confidently 94 assigned. 96 In both cases, performance suffers; in the former, caching efficiency 97 is less than it could be in the common case, In the latter, the 98 server consumes additional resources and delays the response. 100 This specification provides a third solution: updating the caching 101 policy in HTTP trailer fields, after the content has been sent. 102 Doing so allows content to be streamed, while caching policy can be 103 determined after the content is actually generated. 105 1.1. Notational Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 2. The "trailer-update" HTTP Cache Directive 115 The "trailer-update" cache response directive indicates that the 116 caching policy for that response (as indicated by the header field 117 that contains the directive) might be updated by a corresponding 118 trailer field. 120 When it is present as a cache directive in a header field and a 121 trailer field with the same field name is received, a cache that 122 implements this specification MUST completely replace the stored 123 header field value for that response with the trailer field's value, 124 MUST update its handling of that response to account for the new 125 field value (after any outstanding requests are satisfied), and MUST 126 use that value for the header field in responses to future requests 127 satisfied from that cache entry (i.e., the trailer field is 128 "promoted" to a header field). 130 In responses where the trailer field value has replaced the header 131 field value, the "trailer-update" directive will have been removed as 132 part of that process. Note that the presence of "trailer-update" 133 does not guarantee that a trailer field will follow. 135 Caches MAY temporarily store a response that has a caching policy 136 with both the "no-store" and "trailer-update" directives, but MUST 137 NOT reuse that response until the caching policy is updated in a 138 manner that allows it. If the caching policy is not updated or the 139 "no-store" directive is still present in the updated response, the 140 cache MUST immediately and permanently discard the temporarily stored 141 response. 143 For purposes of calculating a stored response's age 144 ([I-D.ietf-httpbis-cache], Section 4.2.3), caches receiving such a 145 trailer SHOULD consider the response_time to be when the trailer is 146 received, but only when calculating resident_time (not 147 response_delay, as that would be counterproductive for the purpose of 148 estimating network delay). 150 2.1. Examples 152 Given a resource that supports this specification but encounters no 153 errors in the generation of a response's content, that response might 154 look like this: 156 HTTP/1.1 200 OK 157 Content-Type: text/html 158 Cache-Control: max-age=3600, trailer-update 160 [body] 162 Caches that do not implement this specification will cache it by the 163 header policy; caches that do implement will see no updates in the 164 trailer and do the same. 166 If a change in caching policy is encountered during the generation of 167 the response content, the resource can prevent reuse by caches that 168 implement this specification by sending: 170 HTTP/1.1 200 OK 171 Content-Type: text/html 172 Cache-Control: max-age=3600, trailer-update 174 [body] 175 Cache-Control: no-store 177 In this case, caches that do not implement this specification will 178 again act as instructed by the header policy, but caches that do 179 implement will see the update in the trailers and prevent reuse of 180 the response after the trailer is received (although it might have 181 been used to satisfy requests that were received in the meantime). 183 If a resource wishes to prevent non-implementing caches from storing 184 the response, they can send: 186 HTTP/1.1 200 OK 187 Content-Type: text/html 188 Cache-Control: no-store; trailer-update 190 [body] 191 Cache-Control: max-age=3600 193 Here, a non-implementing cache will only see "no-store", and so will 194 not store the response. An implementing cache can optimistically 195 store the response based upon "trailer-update", but only allow its 196 reuse after the caching policy is updated to something which permits 197 that in trailers. 199 Note that when a downstream cache does not implement this 200 specification, and also does not forward a message's trailer section 201 (as allowed by HTTP), any updates will effectively be lost, even if 202 further downstream caches do implement. 204 3. IANA Considerations 206 _TBD_ 208 4. Security Considerations 210 _TBD_ 212 5. Normative References 214 [I-D.ietf-httpbis-cache] 215 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 216 Caching", Work in Progress, Internet-Draft, draft-ietf- 217 httpbis-cache-14, 12 January 2021, 218 . 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, 223 DOI 10.17487/RFC2119, March 1997, 224 . 226 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 227 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 228 May 2017, . 230 Authors' Addresses 231 Mark Nottingham 232 Prahran VIC 233 Australia 235 Email: mnot@mnot.net 236 URI: https://www.mnot.net/ 238 James Snell 240 Email: jasnell@gmail.com