idnits 2.17.1 draft-fielding-http-age-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 406 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([RFC2068]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 60: '... MUST transmit an Age header with...' RFC 2119 keyword, line 61: '... HTTP/1.1 caches MUST send an Age head...' RFC 2119 keyword, line 62: '... SHOULD use an arithmetic type of...' RFC 2119 keyword, line 79: '... HTTP/1.1 caches MUST send an Age head...' RFC 2119 keyword, line 83: '...that includes a cache MUST send an Age...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 March 1997) is 9890 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2068' on line 32 ** Obsolete normative reference: RFC 2068 (ref. '1') (Obsoleted by RFC 2616) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Fielding 2 INTERNET-DRAFT U.C. Irvine 3 4 Expires six months after publication date. 26 March 1997 6 Age Header Field in HTTP/1.1 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), 25 or ftp.isi.edu (US West Coast). 27 Discussion of this memo should take place within the HTTP working 28 group (http-wg@cuckoo.hpl.hp.com). 30 Abstract 32 The "Age" response-header field in HTTP/1.1 [RFC 2068] is intended 33 to provide a lower-bound for the estimation of a response message's 34 age (time since generation) by explicitly indicating the amount of 35 time that is known to have passed since the response message was 36 retrieved or revalidated. However, there has been considerable 37 controversy over when the Age header field should be added to a 38 response. This document explains the issues and provides a set of 39 proposed changes for the revision of RFC 2068. 41 1. Problem Statement 43 HTTP/1.1 [1] defines the Age header field in section 14.6: 45 The Age response-header field conveys the sender's estimate of the 46 amount of time since the response (or its revalidation) was generated 47 at the origin server. A cached response is "fresh" if its age does 48 not exceed its freshness lifetime. Age values are calculated as 49 specified in section 13.2.3. 51 Age = "Age" ":" age-value 53 age-value = delta-seconds 55 Age values are non-negative decimal integers, representing time in 56 seconds. 58 If a cache receives a value larger than the largest positive integer 59 it can represent, or if any of its age calculations overflows, it 60 MUST transmit an Age header with a value of 2147483648 (2^31). 61 HTTP/1.1 caches MUST send an Age header in every response. Caches 62 SHOULD use an arithmetic type of at least 31 bits of range. 64 This document focuses on the ambiguous use of the term "caches" in 65 the second-to-last line above. The ambiguity is due to the fact that 66 a cache never sends responses --- only a server application (proxy, 67 gateway, or origin server), which may or may not include a cache, is 68 capable of sending a response. HTTP/1.1 defines a "cache" as 70 A program's local store of response messages and the subsystem 71 that controls its message storage, retrieval, and deletion. A 72 cache stores cachable responses in order to reduce the response 73 time and network bandwidth consumption on future, equivalent 74 requests. Any client or server may include a cache, though a cache 75 cannot be used by a server that is acting as a tunnel. 77 There are two possible interpretations of 79 HTTP/1.1 caches MUST send an Age header in every response. 81 Either 83 a) An HTTP/1.1 server that includes a cache MUST send an Age 84 header field in every response. 85 or 86 b) An HTTP/1.1 server that includes a cache MUST include an Age 87 header field in every response generated from its own cache. 89 The remainder of this document discusses the relative merits of these 90 two options, referred to as "Option A" and "Option B", concluding in 91 section 5 with a set of proposed changes to remove the ambiguity 92 from future editions of the HTTP/1.1 specification. 94 2. Review of HTTP/1.1 Response Age Calculation 96 HTTP/1.1 defines an algorithm for calculating the age of a response 97 message upon receipt by a cache. This document does not propose any 98 modification of this algorithm; we describe it here in order to 99 provide the background necessary to understand the later analyses. 100 We only provide a brief summary here -- for a full explanation, see 101 section 13.2.3 (Age Calculations) of RFC 2068 [1]. 103 Summary of age calculation algorithm, when a cache receives a 104 response: 106 /* 107 * age_value 108 * is the value of Age: header received by the cache with 109 * this response. 110 * date_value 111 * is the value of the origin server's Date: header 112 * request_time 113 * is the (local) time when the cache made the request 114 * that resulted in this cached response 115 * response_time 116 * is the (local) time when the cache received the 117 * response 118 * now 119 * is the current (local) time 120 */ 121 apparent_age = max(0, response_time - date_value); 122 corrected_received_age = max(apparent_age, age_value); 123 response_delay = response_time - request_time; 124 corrected_initial_age = corrected_received_age + response_delay; 125 resident_time = now - response_time; 126 current_age = corrected_initial_age + resident_time; 128 3. Analysis of Option A 130 If we were to assume that 132 An HTTP/1.1 server that includes a cache MUST send an Age 133 header field in every response. 135 is true, then an HTTP/1.1 proxy containing a cache would be required 136 to add an Age header field value to every response that was 137 forwarded, including those that were obtained first-hand from the 138 origin server and never touched by the caching mechanism. This would 139 directly contradict the paragraph in section 13.2.1 of RFC 2068 that 140 states: 142 The expiration mechanism applies only to responses taken from a cache 143 and not to first-hand responses forwarded immediately to the 144 requesting client. 146 and also directly contradicts the last paragraph of section 13.2.3 of 147 RFC 2068 that states: 149 Note that a client cannot reliably tell that a response is first- 150 hand, but the presence of an Age header indicates that a response 151 is definitely not first-hand. 153 If we further assume that the above two paragraphs are in error, then 154 the following example illustrates the effect of the age calculation 155 when a first-hand response passes through a hierarchical system of 156 proxy caches (A, B, C), with each segment taking (a, b, c, d) amount 157 of time to satisfy the request: 159 UA -------> A -------> B ---------> C -------> OS 160 a b c d 162 Since the age calculation includes an estimation of clock skew by 163 each recipient (apparent_age), we also have the variables 165 skewC = max(0, response_time(C) - date_value(OS)); 166 skewB = max(0, response_time(B) - date_value(OS)); 167 skewA = max(0, response_time(A) - date_value(OS)); 168 skewUA = max(0, response_time(UA) - date_value(OS)); 170 then the received age will be calculated as follows: 172 At C: age=max(skewC,0)+d 173 B: age=max(skewB,max(skewC,0)+d)+(c+d) 174 A: age=max(skewA,max(skewB,max(skewC,0)+d)+(c+d))+(b+c+d) 175 UA: age=max(skewUA,max(skewA,max(skewB,max(skewC,0)+d)+(c+d))+ 176 (b+c+d))+(a+b+c+d) 178 Because the response is first-hand, we know that the real age at UA 179 must be less than (a+b+c+d). Note that (a+b+c+d) will always be 180 added by UA, so the cumulative overestimation of the age will be 181 at least 183 max(skewUA,max(skewA,max(skewB,max(skewC,0)+d)+(c+d))+(b+c+d)) 185 If we further assume that all clocks are synchronized (the minimum 186 case), then the age at UA will be estimated as 188 d+(c+d)+(b+c+d)+(a+b+c+d) 190 Note that the above is the minimum overestimation; since the variables 191 skewC, skewB, skewA, and skewUA are all unbounded, the clock skew of 192 each host on the request path adds to the perceived response age of 193 all downstream recipients. Furthermore, a fast clock on the origin 194 will add to the overestimated age at each hop. 196 However, in section 13.2.3 of RFC 2068, we also find 198 In essence, the Age value is the sum of the time that the response 199 has been resident in each of the caches along the path from the 200 origin server, plus the amount of time it has been in transit along 201 network paths. 203 which in our example would imply an age value of (a+b+c+d). Thus, 204 Option A would result in an incorrect calculation of the age value, 205 resulting in an overestimation of age in all cases, with the amount 206 of error bounded only by the synchronization of clocks for each and 207 every recipient along the request chain, plus the cumulative 208 overestimation of the network transit time by each recipient. 210 4. Analysis of Option B 212 If we were to assume that 214 An HTTP/1.1 server that includes a cache MUST include an Age 215 header field in every response generated from its own cache. 217 then an Age header field would not be added to a response that is 218 received first-hand, and thus we would not contradict the sections of 219 RFC 2068 that were quoted above. 221 Using the same example as in the analysis of Option A, the 222 calculation of age with Option B would be as follows: 224 At C: age=max(skewC,0)+d 225 B: age=max(skewB,0)+(c+d) 226 A: age=max(skewA,0)+(b+c+d) 227 UA: age=max(skewUA,0)+(a+b+c+d) 229 Note that there is no cumulative overestimation of the age. The 230 estimated age value at each recipient is only dependent on the skew 231 between the recipient's clock and that of the origin server, plus the 232 total amount of time the request and response has been in transit 233 along the network path. The minimum estimated age at UA is 235 (a+b+c+d) 237 which matches the description provided in section 13.2.3 of RFC 2068. 239 5. Counter-arguments 241 The only argument voiced against Option B is that the calculation is 242 "less conservative" than Option A, and that being "conservative" is 243 better in order to "reduce as much as possible the probability of 244 inadvertently delivering a stale response to a user." 246 If "conservative" means "always overestimates more than the other 247 option", then the argument is certainly true. However, if the 248 purpose of Age was to provide an overestimate, then why stop there? 249 Why not add arbitrary amounts of age to forwarded response, just in 250 case? Why not disable caching entirely? 252 The reason is because HTTP caching is good for the Internet as a 253 whole, and in particular for the owners of the network bandwidth that 254 would be used to satisfy a request that has already been cached. 255 Overestimating response age reduces the effectiveness of caching, and 256 thus results in increased network congestion, added bandwidth 257 requirements, and in some cases additional per-packet charges. 259 Age was created to compensate for the possibility that clock skew 260 between the origin server (represented by the Date header field) and 261 the user agent (represented by the request time) might result in the 262 age of a response being underestimated. Age was created so that 263 HTTP/1.1 caches can communicate the actual observed age, thus 264 providing a lower-bound for the age calculation that would be more 265 reliable than simply calculating the difference between the date 266 stamps. 268 If Age is to be useful, it must be trusted by cache implementers. 269 In order to be trusted by cache implementers, the value of the Age 270 header field must match its definition: the age of the response as 271 observed by the application that generated the response message. 273 Furthermore, Option B is guaranteed to be conservative if all of the 274 applications involved are HTTP/1.1-compliant or if the recipient's 275 clock is equal to or ahead of the origin server clock. The only case 276 in which Option A *might* result in a better estimation than Option B 277 is where one or more HTTP/1.0 caches are in the request chain AND the 278 response came from one of those HTTP/1.0 caches in which it resided 279 for some time AND the user agent's system clock is running behind the 280 origin server's clock. In this one case, Option A would compensate 281 for the clock skew if there existed an HTTP/1.1 cache between the 282 user agent and the HTTP/1.0 cache generating the response AND the 283 HTTP/1.1 cache is better-synchronized to the origin server clock. 285 The above scenario would require a minimum of two proxies in the 286 chain, with at least one outer proxy being an old HTTP/1.0 cache and 287 at least one inner proxy using HTTP/1.1. Given that, for many other 288 reasons (described in RFC 2068), an HTTP/1.0 proxy is incapable of 289 reliably caching HTTP messages in a proxy hierarchy, this scenario 290 is not compelling. 292 In contrast, Option A would overestimate the age on all HTTP/1.1 293 requests, even when there are no longer any HTTP/1.0 proxies. It 294 would also make the age calculation dependent on the clock 295 synchronization of every recipient along the request chain, with the 296 possibility for drastic overestimation if any of the recipients has a 297 bad clock. Option A would therefore make the Age header field value 298 consistently less reliable than simple comparison of date stamps. 300 5. Conclusion and Proposed Changes 302 Option B is the correct interpretation of when the Age header field 303 should be added to an HTTP/1.1 response. The following changes to 304 RFC 2068 will remove the ambiguity. 306 In section 14.6 (Age), replace the sentence 308 HTTP/1.1 caches MUST send an Age header in every response. 310 with 312 An HTTP/1.1 server that includes a cache MUST include an Age 313 header field in every response generated from its own cache. 315 In section 13.2.3 (Age Calculations), replace the paragraph 317 HTTP/1.1 uses the Age response-header to help convey age information 318 between caches. The Age header value is the sender's estimate of the 319 amount of time since the response was generated at the origin server. 320 In the case of a cached response that has been revalidated with the 321 origin server, the Age value is based on the time of revalidation, 322 not of the original response. 324 with 326 HTTP/1.1 uses the Age response-header to convey the estimated age 327 of the response message when obtained from a cache. The Age field 328 value is the cache's estimate of the amount of time since the 329 response was generated or revalidated by the origin server. 331 Delete the following paragraph from section 13.2.3: 333 Note that this correction is applied at each HTTP/1.1 cache along the 334 path, so that if there is an HTTP/1.0 cache in the path, the correct 335 received age is computed as long as the receiving cache's clock is 336 nearly in sync. We don't need end-to-end clock synchronization 337 (although it is good to have), and there is no explicit clock 338 synchronization step. 340 Replace the following two paragraphs from section 13.2.3: 342 When a cache sends a response, it must add to the 343 corrected_initial_age the amount of time that the response was 344 resident locally. It must then transmit this total age, using the Age 345 header, to the next recipient cache. 347 Note that a client cannot reliably tell that a response is first- 348 hand, but the presence of an Age header indicates that a response 349 is definitely not first-hand. Also, if the Date in a response is 350 earlier than the client's local request time, the response is 351 probably not first-hand (in the absence of serious clock skew). 353 with 355 The current_age of a cache entry is calculated by adding the amount 356 of time (in seconds) since the cache entry was last validated by 357 the origin server to the corrected_initial_age. When a response 358 is generated from a cache entry, the server must include a single 359 Age header field in the response with a value equal to the cache 360 entry's current_age. 362 The presence of an Age header field in a response implies that a 363 response is not first-hand. However, the converse is not true, 364 since the lack of an Age header field in a response does not imply 365 that the response is first-hand unless all caches along the 366 request path are compliant with HTTP/1.1 (i.e., older HTTP caches 367 did not implement the Age header field). 369 6. Security Considerations 371 The proposed changes close a potential security problem with HTTP/1.1 372 which would become manifest if a proxy with a slow clock (due to a 373 hardware malfunction, failure to properly set, or caused to be reset 374 by some malevolent agent) adds an Age header field to every response 375 it forwarded, instead of only to those retrieved from its own cache, 376 and thus eliminating the ability of a compliant downstream cache to 377 reduce bandwidth usage on a congested network. Although this is not 378 a serious concern with today's use of HTTP caching, future use of 379 hierarchical cache networks would be impacted. 381 7. Acknowledgements 383 This document was derived from discussions by the author within the 384 HTTP working group, particularly with Jeffrey C. Mogul. 386 9. References 388 [1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. 389 "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068, U.C. Irvine, 390 DEC, MIT/LCS, January 1997. 392 9. Author's Address 394 Roy T. Fielding 395 Department of Information and Computer Science 396 University of California, Irvine 397 Irvine, CA 92697-3425 399 Fax: +1(714)824-1715 400 EMail: fielding@ics.uci.edu