<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.37 -->
<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-nottingham-cache-trailers-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title>Updating HTTP Caching Policy in Trailers</title>
    <seriesInfo name="Internet-Draft" value="draft-nottingham-cache-trailers-00"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization/>
      <address>
        <postal>
          <city>Prahran</city>
          <region>VIC</region>
          <country>Australia</country>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <author initials="J." surname="Snell" fullname="James Snell">
      <organization/>
      <address>
        <email>jasnell@gmail.com</email>
      </address>
    </author>
    <date year="2021"/>
    <area>General</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This specification defines how to update caching policy for a response in HTTP trailer fields, after the content has been sent.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t><em>RFC EDITOR: please remove this section before publication</em></t>
      <t>The issues list for this draft can be found at <eref target="https://github.com/mnot/I-D/labels/cache-trailers">https://github.com/mnot/I-D/labels/cache-trailers</eref>.</t>
      <t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/cache-trailers/">https://mnot.github.io/I-D/cache-trailers/</eref>.</t>
      <t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/cache-trailers">https://github.com/mnot/I-D/commits/gh-pages/cache-trailers</eref>.</t>
      <t>See also the draft's current status in the IETF datatracker, at
<eref target="https://datatracker.ietf.org/doc/draft-nottingham-cache-trailers/">https://datatracker.ietf.org/doc/draft-nottingham-cache-trailers/</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Web content that is "dynamically" generated -- i.e., with the response body streamed by the server to the client as it is created -- is often assumed to be uncacheable. In practice, though, there are some scenarios where caching is beneficial; for example, when a private cache might be able to reuse a personalised, dynamic response for a period, or when such a response can be shared by a number of clients.</t>
      <t>A server choosing a caching policy for such a response faces a conundrum: if an error or other unforeseen condition happens during the generation of the response, that caching policy might be too liberal. Currently, the only available solutions are to:</t>
      <ol spacing="normal" type="1"><li>prevent or severely curtail downstream caching, or</li>
        <li>buffer the response until a caching policy can be confidently assigned.</li>
      </ol>
      <t>In both cases, performance suffers; in the former, caching efficiency is less than it could be in the common case, In the latter, the server consumes additional resources and delays the response.</t>
      <t>This specification provides a third solution: updating the caching policy in HTTP trailer fields, after the content has been sent. Doing so allows content to be streamed, while caching policy can be determined after the content is actually generated.</t>
      <section anchor="notational-conventions" numbered="true" toc="default">
        <name>Notational Conventions</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as
shown here.</t>
      </section>
    </section>
    <section anchor="the-trailer-update-http-cache-directive" numbered="true" toc="default">
      <name>The "trailer-update" HTTP Cache Directive</name>
      <t>The "trailer-update" cache response directive indicates that the caching policy for that response (as indicated by the header field that contains the directive) might be updated by a corresponding trailer field.</t>
      <t>When it is present as a cache directive in a header field and a trailer field with the same field name is received, a cache that implements this specification MUST completely replace the stored header field value for that response with the trailer field's value, MUST update its handling of that response to account for the new field value (after any outstanding requests are satisfied), and MUST use that value for the header field in responses to future requests satisfied from that cache entry (i.e., the trailer field is "promoted" to a header field).</t>
      <t>In responses where the trailer field value has replaced the header field value, the "trailer-update" directive will have been removed as part of that process. Note that the presence of "trailer-update" does not guarantee that a trailer field will follow.</t>
      <t>Caches MAY temporarily store a response that has a caching policy with both the "no-store" and "trailer-update" directives, but MUST NOT reuse that response until the caching policy is updated in a manner that allows it. If the caching policy is not updated or the "no-store" directive is still present in the updated response, the cache MUST immediately and permanently discard the temporarily stored response.</t>
      <t>For purposes of calculating a stored response's age (<xref section="4.2.3" sectionFormat="comma" target="I-D.ietf-httpbis-cache" format="default"/>), caches receiving such a trailer SHOULD consider the response_time to be when the trailer is received, but only when calculating resident_time (not response_delay, as that would be counterproductive for the purpose of estimating network delay).</t>
      <section anchor="examples" numbered="true" toc="default">
        <name>Examples</name>
        <t>Given a resource that supports this specification but encounters no errors in the generation of a response's content, that response might look like this:</t>
        <sourcecode type="http-message">
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600, trailer-update

[body]
</sourcecode>
        <t>Caches that do not implement this specification will cache it by the header policy; caches that do implement will see no updates in the trailer and do the same.</t>
        <t>If a change in caching policy is encountered during the generation of the response content, the resource can prevent reuse by caches that implement this specification by sending:</t>
        <sourcecode type="http-message">
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600, trailer-update

[body]
Cache-Control: no-store
</sourcecode>
        <t>In this case, caches that do not implement this specification will again act as instructed by the header policy, but caches that do implement will see the update in the trailers and prevent reuse of the response after the trailer is received (although it might have been used to satisfy requests that were received in the meantime).</t>
        <t>If a resource wishes to prevent non-implementing caches from storing the response, they can send:</t>
        <sourcecode type="http-message">
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: no-store; trailer-update

[body]
Cache-Control: max-age=3600
</sourcecode>
        <t>Here, a non-implementing cache will only see "no-store", and so will not store the response. An implementing cache can optimistically store the response based upon "trailer-update", but only allow its reuse after the caching policy is updated to something which permits that in trailers.</t>
        <t>Note that when a downstream cache does not implement this specification, and also does not forward a message's trailer section (as allowed by HTTP), any updates will effectively be lost, even if further downstream caches do implement.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t><em>TBD</em></t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><em>TBD</em></t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="I-D.ietf-httpbis-cache" target="https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-14.txt">
        <front>
          <title>HTTP Caching</title>
          <author fullname="Roy T. Fielding">
            <organization>Adobe</organization>
          </author>
          <author fullname="Mark Nottingham">
            <organization>Fastly</organization>
          </author>
          <author fullname="Julian Reschke">
            <organization>greenbytes GmbH</organization>
          </author>
          <date day="12" month="January" year="2021"/>
          <abstract>
            <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document defines HTTP caches and the associated header
   fields that control cache behavior or indicate cacheable response
   messages.

   This document obsoletes RFC 7234.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-14"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization/>
          </author>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIADhvQWAAA71Ya28ctxX9Pr+CVT7UCvYhKUbbrNsiiiTHSm3LteUGRRAI
3BnuDqMZckJytN4a9m/vuZecmX05DoKihrGaB3mf5957OOPxOAs6VGom3jaF
DNosxbPb21fiQuYl3byylc7XQhtx66SulPOZnM+dephlhc2NrLGzcHIRxsYG
2l7KepxjsxqHtGF8cpJBNBaenZydZjkul9atZ8KHIst042YiuNaHs5OTr0/O
MumUnInvlFFOVtnKuvuls20zy+7VGnfFTFyboJxRYXxJirPMB2mKO1lZAx1r
5TNfSxfufmltUH4mjM0aPRM/BpuPBH60KZQJI+GtC04tPK7WdboITud4ldu6
kemixmK80qbSRv2UZbINpXWzTIwzgX/aQMWLiXjZu8+PY2ReSHe/+8a6pTT6
P4i1NTN+kuuAaLxysnTS8BOnlvRW/Ov6Iq6wrQkUsnPECWHRkh+rGhGeiRqh
/4Z+JggKv2gdHC5DaPxsOl2tVpPu7XTL7O8n4o1RVbVh8ff49RtP961NSn+W
nhZ9s6TbCeKUZca6GgsfFC18/fTi7PT0a7q8Hl9OtAqLMVk01z7iY4bcm8Ww
JcvG47GQc3IwR1ZvS+2Fb1SuFzpn/aJQC+TAi9KukEjREmKVyBNUmwhViBQS
EfSNNV4RchnQCY1ioVVVIJ9ADu5Cif0WeDJBlNKLuVJGeNxNkj2Im7p7ST/B
3r1WsqAKyL6Ed+Lq8vr25vVMNJWSUORUbR8UJJLZKmeD5wrWKNG08yr58CU5
Bqu8b+FIpX1gg3kX1xHcoX142ppCyCD+2uVxqUPZzinUU0rnFGGdVnKuKj/d
Lri/T6KS2kK6Uzk598jCXzMSrWFjfKmK46QQmjfVMFSSLm1Zy7b4Kcl/HcXm
pTRLOIKiZWfU502mktLBT5fluJHYe8D4N0oJWXnL6WEj/+hF3jpHKlHtofWU
V3p7fXX7VAAGklBzrxwSG7Je/8YLRuAEcJ6ib00/07LYRUp/rYuiUln2BTUd
Z4uW85plP6h5j5tQSg7iUbFGDSHPVbU+EktuYBQQiNETNRmJFaLBRvfgnNti
TU1HoeoKMV/zW6/cA0Ezup9XmpQAm5q15FjcSfWCs4qXviUB2ALktIadkfNK
TWC2aKiedK7Q/ErbLkv6q5Avypm3NX6QSum09WLFL7qC0lQPBjWXa1k9YZyq
d7IG3ke0EnohWz90NQjA6WUZyATSTdY41cJLLENMrUHf8qoYiRSnIQyxZLFI
W7zGDUv3bV5uVnIqDF/CcA6WFKat5wiVXaQweaTtvAtgXlrryQ95qEXsSl/I
nHBMWUXhubaeCb0QUKmcw3L6T2FDdKmkPfUJLC0013kpm0YZVDAaL9RQ3lL+
6S3M28z6KCJmx6Y+dsFalNKcpt9EXETQV2tOmrCmgtsPAClH2NuqJQ2x/oJF
Ez2dICfqgSBDTuLKKexB8QTsEoVdmYi3Tj/FOzubiHm7WKSG2McEQwd79sKX
EgH3F7pg6wiBemlUgfgDcXOECqu8Qp9FVrnJmxz2sg7/pCteekEl28lXC8Ka
MkQ40ByV9xQqQ8jHBKwK0pq2UhdBaEnJiEBOzyoZAonbKCLYSKWBABUxVbIi
92zrONvosIWq5Npv+T05OHwaZx/gLmEE3doVffRncRB1id8J1u+dP+LSkhQ0
QfQTu/JDu+Ei75oGVSLkfiJFhYKSGjOzOKCP+n4eWmpXQ7eiuffFF8RZZArX
hTUEJ4JZHCvgYYKIGDrei7dvbo9G8a94ecPXr6/++fb69dUlXb95dv78eX/R
rXjz7Obt88vhKj7PsPPi5sWLq5eXcTOeip1HL87/jT+UtqObV7fXNy/Pnx9F
RND4tHlbc6/kYohggdOoB55LPkP2cofSKmjPtxevxOlj8f79HxJV+fAh3fzl
9M+PcUNNKCrjsou3CCDQjmqXjoQgeIh1owPG1YhUeHAT9ANUHUdSUMCOUu7H
kbAcDQxbiUvtiCs8qBjbvaWxsfYVWXTLobwgZCofu8kB5EVeIcOw+xFNkbSv
Hzclk5qIy9SZABAJghjHb6fxeGhR0bjUg3ProoKCK2AT5gjBD9TJ4+RqqG3G
USaTX5vu4OGWKRR4uS1vmKAe2E/PiLeSeCI6kISK6KTHwUzzijl8omZbRc3A
JbZfASNIslNNhUEQdQRLg2bLqAdZtepAZHvDtuwFa+ENo6gn8VWQH9S6KSqK
F8+GTUkArsyZ7yc1Shi12lL/KNayNGth28CnHxLl1C/glCEOAw//PDYVxxHC
0QCfgrLpxg4CkIjOFk/GLNrQOjUI7wWLhbP1MMqUUHREEY8i19mLBTMk9NAa
XLo4Yje3FB/H0THojlxkX060nZplSlax70SKejhUUQPmVhrVW0pccduNBJ4a
hWhwfuxTA6MxLDwf8dRQbRHOwArW7Sux8AD0UixbiUNdUGnjPqBhwsJSh4f/
3BK8QJcTQdWNdWBl1ToCcZOrsKiyr6ONmmcc8vhl340d8+aj2DM/GQr0rnkb
RNfGE2/bBmYkA4cmnO8bAlcxZr1RqUDS7NKYZ9eLT2ymMHUCEiI3DN9oEQBf
oHh1jSRRgW7vJr/qGCl7pHGGL7TkAqc4gJLAxkhcCu1z6SKE9mJebFKCp7Ct
aV1jCZzEOGWVt1Wc+3J3PSofZxvx6P37w4ffkXiTjoiPJ2eTrz58OI4sSHV9
jGd/pKgdYtKwJEqjix2qdhd03Q09Js+bdbPVHCnP/TzbcgKymM5FWY8oLb14
Zkk04GJaVx0b40ZFIzYejR6GppJCRZFC39B11GFUoC86kXVRyYNrXMUzBdjF
dxBgItCZoUVlvm2QlsP9m7xBEUYrCEqRrvfHw20WLjfzk2jQaAfmcchV1t6D
hd/H8zx49cePH/mDyhhk0iO1Gc3w6enkVJydnIibf2QXUdz4dt2oGaD0LkzL
UFexpsf01ln6ViPfjbH9b1/96eRkJLYLMst+pAPhT6SsbwZsXWG5SvpZdigU
3Eoi6jFvt4d7LLYnHcQ6mYM83oxDDUUwGtOHsEMRk2XbT19q1xTR+AWAFu9X
dp8ZVMZvOhptJkUNMCA2251qYmuar7d8+dXAYC3aBY3I/3ced/Z0TS3m9zrR
1niEyX9PtuVSUsfN4+cBOtihCPeYXcxHrPzPA2DoqDsAiMel7TTspm84ZBzo
PeAtVfwCQQCNdTZMX4jjDxiRX6wHwhEbjmIOkgQlw2qFyYpeddxhsQfMij5w
MX3p7DXWjHtvCYgpEkxiKCsdOLemSDxIEXr+h9DpYPDkN8JmE2oROs8QDaK5
h52KueQeTwkdZmlkgjhR8gKCWGQWW2dfcW7EAZkUB9sg2hrNnD9xHdgs5pKy
2OJmj2xsTB4mBUyD0/eh4Wj6SWZByLC1CvwaR15MRhrjugMIQSLhFGgYmFr6
TrXz3UMNBO3XqiwGjL9E9usx31ZEGMBzIgwwSjqwd5996ZzFTsZaJJwwDV/3
vZUzoBaLSG0QE8zSyno0PoIrfXlatI6/N+1a7rfqNh4yr89fntM5nXmBTEf1
u9tvL+/oLZgGem9Yf2oFf+icy/w++y83ZxJjDhoAAA==

-->

</rfc>
