idnits 2.17.1 draft-mogul-http-revalidate-01.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-26) 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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([2], [3], [1]), 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 163: '...ctive, the cache MAY use that response...' RFC 2119 keyword, line 164: '...equent request, but a proxy cache MUST...' RFC 2119 keyword, line 183: '... request, it MUST NOT return that ...' RFC 2119 keyword, line 187: '...ctive, the cache MAY use the entity of...' RFC 2119 keyword, line 188: '...o a subsequent request, but MUST first...' (11 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 (27 May 1997) is 9831 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) -- Missing reference section? '1' on line 41 looks like a reference -- Missing reference section? '2' on line 488 looks like a reference -- Missing reference section? '3' on line 482 looks like a reference -- Missing reference section? '4' on line 370 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group J. C. Mogul, DECWRL 3 Internet-Draft 27 May 1997 4 Expires: 30 November 1997 6 Forcing HTTP/1.1 proxies to revalidate responses 8 draft-mogul-http-revalidate-01.txt 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by 20 other documents at any time. It is inappropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as "work in progress." 24 To learn the current status of any Internet-Draft, please 25 check the "1id-abstracts.txt" listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za 27 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 28 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 29 West Coast). 31 Distribution of this document is unlimited. Please send 32 comments to the HTTP working group at 33 . Discussions of the working 34 group are archived at 35 . General 36 discussions about HTTP and the applications which use HTTP 37 should take place on the mailing list. 39 ABSTRACT 41 The HTTP/1.1 specification [1] currently defines a 42 ``proxy-revalidate'' Cache-control directive, which forces 43 a proxy to revalidate a stale response before using it in a 44 reply. There is no mechanism defined that forces a proxy, 45 but not an end-client, to revalidate a fresh response. The 46 lack of such a mechanism is due to an error in drafting 47 RFC2068, and appears to create problems for use of the 48 Authorization header, the Digest Access Authentication 49 extension [2], the State Management Mechanism [3], and 50 several other proposed extensions. This document discusses 51 the problem and several possible solutions, and proposes to 52 add a new ``s-maxage'' directive as the best available 53 solution. 55 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 57 TABLE OF CONTENTS 59 1 Introduction 2 60 2 Problems with proxy-revalidate 3 61 3 Possible alternatives 5 62 3.1 Alternatives not requiring changes to RFC2068 5 63 3.2 Alternatives that require changes to RFC2068 6 64 4 Proposed solution 8 65 5 Security Considerations 10 66 6 Acknowledgements 10 67 7 References 10 68 8 Author's address 10 70 1 Introduction 72 HTTP/1.1 introduces a ``Cache-control'' header to allow origin 73 servers and clients to impose fine-grained control over the operation 74 of HTTP caches. One important aspect of HTTP caching is whether a 75 cache should ``revalidate'' a cached response with the origin server, 76 before using the response as a cache hit. In cases where the use of 77 an invalid cache entry could lead to serious error, such as the 78 violation of an authentication policy, or incorrect behavior of an 79 online shopping application, proper revalidation could be crucial. 80 On the other hand, caching can yield significant performance 81 benefits, and so we want to make caching as effective as possible. 83 Note: HTTP caches normally revalidate a cached response by 84 sending a conditional GET to the origin server. This may be 85 done using the ``If-none-match'' request header or the 86 ``If-modified-since'' request header. If the server would 87 return the same response as the cached response, the server may 88 reply with a status code of 304 (Not Modified). While this 89 does involve a message exchange, by avoiding the transmission 90 of the entity body, a revalidation is often much cheaper than 91 an unconditional retrieval. 93 Regarding the terms ``fresh'' and ``stale'': a cached response 94 is considered to be fresh if its current age is less than its 95 maximum allowed age. A cached response is stale otherwise. 96 Normally, only stale responses need to be revalidated; a fresh 97 response is inherently usable without revalidation, until it 98 reaches its maximum age. 100 During the design of HTTP/1.1, it was realized that different 101 revalidation policies might be applied to end-client caches (e.g., in 102 browsers) and to intermediate proxy caches. For example, a proxy 103 cache might be shared between multiple users (raising security 104 considerations), or it might be operated by someone whose interests 105 in reducing transmission costs do not coincide with the interest of 106 the ultimate client or origin server in preserving certain kinds of 107 application semantics. 109 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 111 It was also realized that in some cases, it might sometimes be 112 appropriate to configure a cache to be ``loose'' in its behavior for 113 stale responses. That is, in such a situation, the cache might 114 return a stale response without revalidating it. This might be done, 115 for example, if the network connection between the cache and the 116 origin server is not working, or if the cost or delay for 117 revalidation is prohibitively high. 119 There is an obvious potential contradiction between the occasional 120 requirement for strict revalidation of certain responses, and the 121 occasional desire to allow loose operation of some HTTP caches. 122 HTTP/1.1 resolves this by allowing (although not encouraging) loose 123 operation as the default, but by providing a protocol mechanism for 124 origin servers or end-clients to insist on mandatory strict operation 125 when necessary. This is done using the ``Cache-control'' header, 126 which can carry a number of cache-control directives. In particular, 127 these directives are defined in section 14.9 of RFC2068: 129 - max-age=NNN 130 Sets the maximum age for this response to NNN seconds. By 131 itself, does not force strict revalidation behavior. 133 - no-cache 134 Prevents any caching of this response. 136 - private 137 Prevents any caching by a shared cache. 139 - must-revalidate 140 Requires that an HTTP/1.1 cache revalidate the response 141 before using it, if the response is stale. 143 - proxy-revalidate 144 Requires that an HTTP/1.1 proxy cache revalidate the 145 response before using it, if the response is stale; does 146 not affect an end-client cache. 148 2 Problems with proxy-revalidate 150 The fundamental problem with proxy-revalidate, as defined in RFC2068, 151 is that it does not require a proxy cache to revalidate a fresh 152 response before using it. However, there are several circumstances 153 in which it is desirable or necessary to force a proxy cache to 154 revalidate a response that, to an end-client cache, would appear to 155 be fresh. 157 In section 14.8 of RFC2068, defining the ``Authorization'' header, 158 this language appears: 160 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 162 1. If the response includes the "proxy-revalidate" 163 Cache-Control directive, the cache MAY use that response in 164 replying to a subsequent request, but a proxy cache MUST 165 first revalidate it with the origin server, using the 166 request-headers from the new request to allow the origin 167 server to authenticate the new request. 169 While this could be read as modifying the definition of 170 proxy-revalidate from section 14.9.4, it was in fact not intended as 171 a modification. Rather, the author of these two sections of RFC2068 172 (me!) failed to notice the conflicting intentions of these two uses 173 of proxy-revalidate. 175 In section 2.1.2 of RFC2069 [2] (the specification of the Digest 176 Access Authentication extension to HTTP/1.1), this language appears: 178 Implementors should be aware of how authenticated 179 transactions interact with proxy caches. The HTTP/1.1 180 protocol specifies that when a shared cache (see section 181 13.10 of [2]) has received a request containing an 182 Authorization header and a response from relaying that 183 request, it MUST NOT return that response as a reply to any 184 other request, unless one of two Cache-control (see section 185 14.9 of [2]) directives was present in the response. If the 186 original response included the ``must-revalidate'' 187 Cache-control directive, the cache MAY use the entity of that 188 response in replying to a subsequent request, but MUST first 189 revalidate it with the origin server, using the request 190 headers from the new request to allow the origin server to 191 authenticate the new request. Alternatively, if the original 192 response included the ``public'' Cache-control directive, the 193 response entity MAY be returned in reply to any subsequent 194 request. 196 This discussion appears to be in error, since its implication that 197 ``must-revalidate'' always MUST cause a revalidation does not cover 198 the case of apparently fresh responses. In fact, discussion with one 199 of the authors of RFC2069 has confirmed that he understood that 200 RFC2068 had provided a ``proxy must revalidate even if fresh'' 201 directive, which it does not. 203 In section 4.2.3 of RFCXXXX [3] (the specification of the State 204 Management Mechanism for HTTP/1.1), this language appears: 206 The origin server should send [one of] the following 207 additional HTTP/1.1 response headers, depending on 208 circumstances: 210 * To suppress caching of a private document in shared caches: 211 Cache-control: private. 213 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 215 * To allow caching of a document and require that it be 216 validated before returning it to the client: Cache-control: 217 must-revalidate. 219 * To allow caching of a document, but to require that proxy 220 caches (not user agent caches) validate it before returning 221 it to the client: Cache-control: proxy-revalidate. 223 * To allow caching of a document and request that it be 224 validated before returning it to the client (by 225 ``pre-expiring'' it): Cache-control: max-age=0. Not all 226 caches will revalidate the document in every case. 228 Here again there seems to be a (false) assumption that 229 must-revalidate and proxy-revalidate cause revalidation even of fresh 230 responses. 232 Finally, the proposed Hit-Metering extension to HTTP/1.1 [4] depends 233 on a mechanism whereby an origin server can require proxy caches to 234 revalidate a response before every use, without requiring end-client 235 caches to do the same thing (which would be prohibitively 236 inefficient). 238 In summary, there is a clear need for a Cache-control mechanism that 239 allows an origin server to specify that a proxy cache (more 240 accurately, a shared cache) must always revalidate a response, while 241 allowing end-clients (more accurately, private caches) to cache it 242 without revalidation (perhaps for a limited period). 244 3 Possible alternatives 246 3.1 Alternatives not requiring changes to RFC2068 247 Assuming that we do want a mechanism that allows an origin server to 248 specify that a proxy must always revalidate a response, while 249 allowing end-clients to cache it without revalidation, we could 250 certainly do this by modifying the HTTP/1.1 specification proposed in 251 RFC2068. Would it be possible to do this without modifying RFC2068, 252 possibly by using a combination of existing Cache-control directives 253 to approximate the desired behavior? 255 One solution would simply to use ``Cache-control: private''. This 256 would preserve any necessary semantics (because it would prevent any 257 and all proxy caching of the response). However, it is much less 258 efficient; because ``private'' prevents a shared cache from even 259 storing the response, it cannot do a conditional request for 260 subsequent references. Hence, this approach would lead to much 261 unnecessary transmission of entity bodies when we could be using 304 262 (Not Modified) responses. 264 Another approach would be to use ``Cache-control: proxy-revalidate, 266 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 268 max-age=0''. This allows proxies to store the response and forces 269 them to revalidate it on every reference. However, it also implies 270 that strict end-user caches should revalidate on every reference as 271 well, which could cause even more unnecessary traffic than 272 ``Cache-control: private'' would. 274 In short, there does not appear to be a way to use the existing 275 RFC2068 mechanisms to preserve both the necessary semantics and 276 optimal cache performance. 278 3.2 Alternatives that require changes to RFC2068 279 Several proposals have been made for modifications to RFC2068 to 280 resolve this problem. 282 We could redefine proxy-revalidate to mean ``always revalidate, even 283 if the response is fresh.'' However, this would leave us either with 284 no way to allow strict caches to use a response while it is fresh, or 285 with no way to force loose caches to revalidate certain responses. 287 The other proposals all involve adding one new Cache-control 288 directive, while preserving the current meaning of the existing 289 proxy-revalidate directive: 291 - proxy-mustcheck 292 This would mean that a proxy, but not an end-client, would 293 have to revalidate the response even it is fresh 295 - s-maxage=NNN 296 This would mean defining separate maximum ages for shared 297 (normally proxy) caches and for private (normally 298 end-client) caches. The existing max-age (or Expires) 299 value would continue to apply to private caches, and would 300 continue to apply to shared caches if the s-maxage 301 directive were not present. However, if s-maxage is 302 present, then it would override the max-age (or Expires) 303 limit for shared caches, but would be ignored by private 304 caches. 306 - agent-maxage=NNN 307 This would also mean defining separate maximum ages for 308 proxy caches and for end-client caches. The existing 309 max-age (or Expires) value would continue to apply to proxy 310 caches, and would continue to apply to end-client caches if 311 the agent-maxage directive were not present. However, if 312 agent-maxage is present, then it would override the max-age 313 (or Expires) limit for end-clients, but would be ignored by 314 proxy caches. 316 One option would be to make either ``s-maxage'' or ``agent-maxage'' 317 always strict: that is, they would imply that a proxy or end-client, 318 respectively, (or shared and private caches, respectively) would be 320 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 322 required to revalidate a stale response. Alternatively, they could 323 be combined with a ``must-revalidate'' directive to force strict 324 behavior, but would otherwise allow loose behavior. 326 Each of these proposals would solve the existing problem, would be 327 simple to specify, and would probably not require significant 328 implementation complexity or overhead. However, we should probably 329 choose just one of these options; what are the relative merits? 331 The proxy-mustcheck approach is clearly the simplest, but gives up 332 the possibility of separate control over proxy and end-client 333 expiration times. Since this orthogonality could potentially be 334 useful, it seems more useful to adopt the s-maxage or agent-maxage 335 proposals. 337 If one assumes that this change could be made to the HTTP/1.1 338 specification before the permanent deployment of any HTTP/1.1 339 proxies, there at first seems to be no obvious reason to prefer one 340 to the other. That is, this header 342 Cache-control: max-age=10,s-maxage=3 344 and this one 346 Cache-control: max-age=3,agent-maxage=10 348 both express the same semantics in the same number of bytes. 350 However, if we also adopt the rule that s-maxage implies the presence 351 of proxy-revalidate, then in order to express the semantics of 353 Cache-control: max-age=10,s-maxage=3 355 the origin server would have to send 357 Cache-control: max-age=3,agent-maxage=10,proxy-revalidate 359 which is somewhat more expensive. 361 Also, if we do adopt the Hit-metering proposal [4], the s-maxage 362 approach seems preferable, because it would allow the necessary 363 header rewriting to be accomplished by simple addition of a 364 directive, rather than more elaborate rewriting. For example, if the 365 origin server sends a hit-metered response with 367 Cache-control: max-age=10 369 then it would be rewritten (at the appropriate proxy, if necessary; 370 see [4] for details) as 372 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 374 Cache-control: max-age=10,s-maxage=0 376 using the s-maxage alternative, but would have to be rewritten as 378 Cache-control: max-age=0,agent-maxage=10 380 using the agent-maxage proposal. 382 On the other hand, if we cannot make the necessary change to the 383 specification before the deployment of HTTP/1.1 proxies, then the 384 agent-maxage proposal is somewhat safer in terms of semantics. That 385 is, if HTTP/1.1 proxies are deployed that do not understand the 386 s-maxage directive, the use of agent-maxage will not cause these 387 proxies to avoid revalidating fresh responses. This is because they 388 will presumably carry a ``max-age=0'' directive, and so not appear to 389 be fresh to these proxies. 391 Unfortunately, if we fail to change the specification before the 392 permanent deployment of HTTP/1.1 end-clients, then we may face a 393 performance problem with the use of agent-maxage: clients that do 394 not understand this new directive might do many more revalidations 395 than necessary, and so cause excessive network and server loading, as 396 well as unnecessary delays. 398 Ultimately, therefore, it would be best if we made this specification 399 change before any permanent deployment of HTTP/1.1 proxies or 400 clients. If we do so, then it seems more efficient to use the 401 s-maxage mechanism. 403 4 Proposed solution 405 The HTTP/1.1 specification in RFC2068 should be changed, in section 406 14.9 (Cache-Control), in the following ways: 408 - The grammar for cache-response-directive should include a 409 new alternative: 411 | "s-maxage" "=" delta-seconds 413 There is no need for a corresponding change to the grammar 414 for cache-request-directive. 416 - Section 14.9.3 should include, after the second paragraph 417 (which starts with ``If a response includes ...''), this 418 new paragraph: 420 If a response includes a s-maxage directive, then 421 for a shared cache (but not for a private cache), 422 the maximum age specified by this directive 423 overrides the maximum age specified by either the 425 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 427 max-age directive or the Expires header. The 428 s-maxage directive also implies the semantics of 429 the proxy-revalidate directive (see section 430 14.9.4), i.e., that the shared cache MUST NOT use 431 the entry after it becomes stale to respond to a 432 subsequent request without first revalidating it 433 with the origin server. The s-maxage directive is 434 always ignored by a private cache. 436 - In section 13.4, the list of response headers and 437 directives implicitly allowing cachability should include 438 ``s-maxage'' after ``max-age''. 440 - In section 14.8 (Authorization), this paragraph: 442 1. If the response includes the "proxy-revalidate" 443 Cache-Control directive, the cache MAY use that 444 response in replying to a subsequent request, but a 445 proxy cache MUST first revalidate it with the 446 origin server, using the request-headers from the 447 new request to allow the origin server to 448 authenticate the new request. 450 should become 452 1. If the response includes the "proxy-revalidate" 453 Cache-Control directive, the cache MAY use that 454 response in replying to a subsequent request, but 455 if the response is stale, a proxy cache MUST first 456 revalidate it with the origin server, using the 457 request-headers from the new request to allow the 458 origin server to authenticate the new request. 460 This paragraph 462 2. If the response includes the "must-revalidate" 463 Cache-Control directive, the cache MAY use that 464 response in replying to a subsequent request, but 465 all caches MUST first revalidate it with the origin 466 server, using the request-headers from the new 467 request to allow the origin server to authenticate 468 the new request. 470 should become 472 2. If the response includes the "must-revalidate" 473 Cache-Control directive, the cache MAY use that 474 response in replying to a subsequent request, but 475 if the response is stale, all caches MUST first 476 revalidate it with the origin server, using the 477 request-headers from the new request to allow the 478 origin server to authenticate the new request. 480 Internet-Draft HTTP proxy revalidation 27 May 1997 17:59 482 Additionally, RFC2069 [2] and RFCXXXX [3] should probably be modified 483 to suggest the use of ``s-maxage=0'' and/or ``max-age=0, 484 must-revalidate'' to force proxies to revalidate a response. 486 5 Security Considerations 488 The proposed Digest Access Authentication extension [2] depends upon 489 a mechanism to force proxies to always revalidate certain responses. 490 Whether or not the proposal in this document is adopted, the Digest 491 Access Authentication extension requires modification to reflect the 492 option chosen (unless the HTTP/1.1 specification is revised to make 493 ``proxy-revalidate'' apply to fresh as well as to stale responses.) 495 6 Acknowledgements 497 Several people contributed to my understanding of this issue, 498 including Roy Fielding, Koen Holtman, Paul Leach, Ingrid Melve, and 499 Anselm Baird-Smith. However, the proposal in this document is my 500 fault alone. 502 7 References 504 1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk 505 Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol -- 506 HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997. 508 2. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, 509 E. Sink, L. Stewart. An Extension to HTTP: Digest Access 510 Authentication. RFC 2069, HTTP Working Group, January, 1997. 512 3. D. Kristol, L. Montulli. HTTP State Management Mechanism. RFC 513 2109, HTTP Working Group, February, 1997. 515 4. J. Mogul and P. Leach. Simple Hit-Metering and Usage-Limiting 516 for HTTP. Internet Draft draft-ietf-http-hit-metering-02.txt, HTTP 517 Working Group, March, 1997. This is a work in progress. 519 8 Author's address 521 Jeffrey C. Mogul 522 Western Research Laboratory 523 Digital Equipment Corporation 524 250 University Avenue 525 Palo Alto, California, 94305, USA 526 Email: mogul@wrl.dec.com