Changeset 442


Ignore:
Timestamp:
Feb 2, 2009, 12:18:21 PM (11 years ago)
Author:
julian.reschke@…
Message:

Bring ABNF stuff in-line with main branch.

Location:
draft-ietf-httpbis/latest-roy
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest-roy/p6-cache.html

    r441 r442  
    369369      <link rel="Index" href="#rfc.index">
    370370      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    371       <link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2">
    372       <link rel="Chapter" title="3 Cache Operation" href="#rfc.section.3">
    373       <link rel="Chapter" title="4 Header Field Definitions" href="#rfc.section.4">
    374       <link rel="Chapter" title="5 History Lists" href="#rfc.section.5">
    375       <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
    376       <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
    377       <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
    378       <link rel="Chapter" href="#rfc.section.9" title="9 References">
     371      <link rel="Chapter" title="2 Cache Operation" href="#rfc.section.2">
     372      <link rel="Chapter" title="3 Header Field Definitions" href="#rfc.section.3">
     373      <link rel="Chapter" title="4 History Lists" href="#rfc.section.4">
     374      <link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5">
     375      <link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6">
     376      <link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7">
     377      <link rel="Chapter" href="#rfc.section.8" title="8 References">
    379378      <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A">
    380379      <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B">
     
    515514               <li class="tocline1">1.2&nbsp;&nbsp;&nbsp;<a href="#intro.terminology">Terminology</a></li>
    516515               <li class="tocline1">1.3&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
    517             </ul>
    518          </li>
    519          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#notation">Notational Conventions and Generic Grammar</a></li>
    520          <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Cache Operation</a><ul class="toc">
    521                <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a><ul class="toc">
    522                      <li class="tocline1">3.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></li>
     516               <li class="tocline1">1.4&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul class="toc">
     517                     <li class="tocline1">1.4.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
     518                     <li class="tocline1">1.4.2&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
    523519                  </ul>
    524520               </li>
    525                <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></li>
    526                <li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul class="toc">
    527                      <li class="tocline1">3.3.1&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a><ul class="toc">
    528                            <li class="tocline1">3.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Using Heuristic Freshness</a></li>
     521            </ul>
     522         </li>
     523         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Cache Operation</a><ul class="toc">
     524               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a><ul class="toc">
     525                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></li>
     526                  </ul>
     527               </li>
     528               <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></li>
     529               <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul class="toc">
     530                     <li class="tocline1">2.3.1&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a><ul class="toc">
     531                           <li class="tocline1">2.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Using Heuristic Freshness</a></li>
    529532                        </ul>
    530533                     </li>
    531                      <li class="tocline1">3.3.2&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li>
    532                      <li class="tocline1">3.3.3&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li>
     534                     <li class="tocline1">2.3.2&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li>
     535                     <li class="tocline1">2.3.3&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li>
    533536                  </ul>
    534537               </li>
    535                <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a></li>
    536                <li class="tocline1">3.5&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
    537                <li class="tocline1">3.6&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
    538                <li class="tocline1">3.7&nbsp;&nbsp;&nbsp;<a href="#combining.headers">Combining Responses</a></li>
     538               <li class="tocline1">2.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a></li>
     539               <li class="tocline1">2.5&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
     540               <li class="tocline1">2.6&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
     541               <li class="tocline1">2.7&nbsp;&nbsp;&nbsp;<a href="#combining.headers">Combining Responses</a></li>
    539542            </ul>
    540543         </li>
    541          <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
    542                <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li>
    543                <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul class="toc">
    544                      <li class="tocline1">4.2.1&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li>
    545                      <li class="tocline1">4.2.2&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li>
    546                      <li class="tocline1">4.2.3&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li>
     544         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
     545               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li>
     546               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul class="toc">
     547                     <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li>
     548                     <li class="tocline1">3.2.2&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li>
     549                     <li class="tocline1">3.2.3&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li>
    547550                  </ul>
    548551               </li>
    549                <li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li>
    550                <li class="tocline1">4.4&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li>
    551                <li class="tocline1">4.5&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li>
    552                <li class="tocline1">4.6&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a></li>
     552               <li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li>
     553               <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li>
     554               <li class="tocline1">3.5&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li>
     555               <li class="tocline1">3.6&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a></li>
    553556            </ul>
    554557         </li>
    555          <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li>
    556          <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul class="toc">
    557                <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#message.header.registration">Message Header Registration</a></li>
     558         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li>
     559         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul class="toc">
     560               <li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#message.header.registration">Message Header Registration</a></li>
    558561            </ul>
    559562         </li>
    560          <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
    561          <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
    562          <li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
    563                <li class="tocline1">9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    564                <li class="tocline1">9.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     563         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
     564         <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
     565         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
     566               <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     567               <li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    565568            </ul>
    566569         </li>
     
    596599      <p id="rfc.section.1.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to reuse a prior
    597600         response message to satisfy a current request. In some cases, a stored response can be reused without the need for a network
    598          request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy
    599          the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see <a href="#validation.model" title="Validation Model">Section&nbsp;3.4</a>).
     601         request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy
     602         the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
    600603      </p>
    601604      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.terminology" href="#intro.terminology">Terminology</a></h2>
     
    662665      <p id="rfc.section.1.3.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."
    663666      </p>
    664       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1>
    665       <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: <span class="comment">[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 5234, see &lt;<a href="http://ietf.org/wg/httpbis/trac/ticket/36">http://ietf.org/wg/httpbis/trac/ticket/36</a>&gt;.]</span>
    666       </p>
    667       <div id="rfc.figure.u.1"></div> <pre class="inline">  <a href="#notation" class="smpl">DIGIT</a>         = &lt;DIGIT, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    668   <a href="#notation" class="smpl">DQUOTE</a>        = &lt;DQUOTE, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    669   <a href="#notation" class="smpl">SP</a>            = &lt;SP, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    670 </pre> <div id="rfc.figure.u.2"></div> <pre class="inline">  <a href="#notation" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    671   <a href="#notation" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    672 </pre> <div id="abnf.dependencies">
    673          <p id="rfc.section.2.p.4">          The ABNF rules below are defined in other parts:</p>
    674       </div>
    675       <div id="rfc.figure.u.3"></div>   <pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>&gt;
    676   <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a>&gt;
    677   <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>&gt;
    678   <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a>&gt;
    679   <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>&gt;
    680 </pre> <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Cache Operation</a></h1>
    681       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
    682       <p id="rfc.section.3.1.p.1">A cache <em class="bcp14">MAY</em> store a response to any request, provided that:
     667      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     668      <p id="rfc.section.1.4.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
     669         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
     670         and WSP (whitespace).
     671      </p>
     672      <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a>&nbsp;<a id="core.rules" href="#core.rules">Core Rules</a></h3>
     673      <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
     674      </p>
     675      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
     676  <a href="#core.rules" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
     677  <a href="#core.rules" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
     678</pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
     679      <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p>
     680      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>&gt;
     681  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a>&gt;
     682  <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>&gt;
     683  <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a>&gt;
     684  <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>&gt;
     685</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Cache Operation</a></h1>
     686      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
     687      <p id="rfc.section.2.1.p.1">A cache <em class="bcp14">MAY</em> store a response to any request, provided that:
    683688      </p>
    684689      <ul>
    685          <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;4.2</a>) does not appear in request or response headers.
    686          </li>
    687          <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Incomplete Responses">Section&nbsp;3.1.1</a>).
     690         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers.
     691         </li>
     692         <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Incomplete Responses">Section&nbsp;2.1.1</a>).
    688693         </li>
    689694      </ul>
    690       <p id="rfc.section.3.1.p.2">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration
     695      <p id="rfc.section.2.1.p.2">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration
    691696         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    692697      </p>
    693       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></h3>
    694       <p id="rfc.section.3.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response <span class="comment">[rfc.comment.1: Indeed? Is this new? --JRE]</span>. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
    695       </p>
    696       <p id="rfc.section.3.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
    697       </p>
    698       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
    699       <p id="rfc.section.3.2.p.1">For a given request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
     698      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></h3>
     699      <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response <span class="comment">[rfc.comment.1: Indeed? Is this new? --JRE]</span>. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
     700      </p>
     701      <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
     702      </p>
     703      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
     704      <p id="rfc.section.2.2.p.1">For a given request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
    700705      </p>
    701706      <ul>
    702707         <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.2: TBD]</span>), and
    703708         </li>
    704          <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;3.6</a>), and
    705          </li>
    706          <li>the stored response is either fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a>) or allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;3.3.3</a>), and
    707          </li>
    708          <li>the presented request and stored response are free from directives that would prevent it (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;4.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;4.4</a>).
     709         <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), and
     710         </li>
     711         <li>the stored response is either fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>) or allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>), and
     712         </li>
     713         <li>the presented request and stored response are free from directives that would prevent it (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>).
    709714         </li>
    710715      </ul>
    711       <p id="rfc.section.3.2.p.2"> <span class="comment">[rfc.comment.3: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span>
    712       </p>
    713       <p id="rfc.section.3.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
     716      <p id="rfc.section.2.2.p.2"> <span class="comment">[rfc.comment.3: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span>
     717      </p>
     718      <p id="rfc.section.2.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
    714719      </p>
    715720      <ul>
    716          <li>the criteria for non-shared caches above are met (including directives for shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;4.2</a>), and
    717          </li>
    718          <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;4.2</a>).
     721         <li>the criteria for non-shared caches above are met (including directives for shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a>), and
     722         </li>
     723         <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>).
    719724         </li>
    720725      </ul>
    721       <p id="rfc.section.3.2.p.4">All responses satisfied from cache <em class="bcp14">MUST</em> include an appropriate Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;4.1</a>).
    722       </p>
    723       <p id="rfc.section.3.2.p.5">All request methods other than GET and HEAD <em class="bcp14">MUST</em> be written through the cache to the origin server. Note that such requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;3.5</a>.
    724       </p>
    725       <p id="rfc.section.3.2.p.6">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one applicable response is stored. They <em class="bcp14">MAY</em> also send a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
    726       </p>
    727       <p id="rfc.section.3.2.p.7">In the process of determining whether a stored response is fresh or not, a cache <em class="bcp14">MAY</em> validate that response (see <a href="#validation.model" title="Validation Model">Section&nbsp;3.4</a>).
    728       </p>
    729       <p id="rfc.section.3.2.p.8"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
    730       </p>
    731       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
    732       <p id="rfc.section.3.3.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. When a response is "fresh" in
     726      <p id="rfc.section.2.2.p.4">All responses satisfied from cache <em class="bcp14">MUST</em> include an appropriate Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>).
     727      </p>
     728      <p id="rfc.section.2.2.p.5">All request methods other than GET and HEAD <em class="bcp14">MUST</em> be written through the cache to the origin server. Note that such requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
     729      </p>
     730      <p id="rfc.section.2.2.p.6">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one applicable response is stored. They <em class="bcp14">MAY</em> also send a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     731      </p>
     732      <p id="rfc.section.2.2.p.7">In the process of determining whether a stored response is fresh or not, a cache <em class="bcp14">MAY</em> validate that response (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
     733      </p>
     734      <p id="rfc.section.2.2.p.8"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
     735      </p>
     736      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     737      <p id="rfc.section.2.3.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. When a response is "fresh" in
    733738         the cache, it can be used to satisfy subsequent requests without contacting the origin server. This is also referred to as
    734739         "expiration."<span class="comment">[rfc.comment.5: What exactly is called 'expiration'? --JRE]</span>.
    735740      </p>
    736       <p id="rfc.section.3.3.p.2">Expiration applies only to responses taken from a cache and not to first-hand responses. It cannot be used to force a user
    737          agent to refresh its display or reload a resource; its semantics apply only to caches. See <a href="#history.lists" title="History Lists">Section&nbsp;5</a> for an explanation of the difference between caches and history mechanisms.
    738       </p>
    739       <p id="rfc.section.3.3.p.3">The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future,
    740          using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;4.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
     741      <p id="rfc.section.2.3.p.2">Expiration applies only to responses taken from a cache and not to first-hand responses. It cannot be used to force a user
     742         agent to refresh its display or reload a resource; its semantics apply only to caches. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
     743      </p>
     744      <p id="rfc.section.2.3.p.3">The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future,
     745         using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
    741746         likely to change in a semantically significant way before the expiration time is reached. This normally preserves cache correctness,
    742747         as long as the server's expiration times are carefully chosen.
    743748      </p>
    744       <p id="rfc.section.3.3.p.4">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
     749      <p id="rfc.section.2.3.p.4">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
    745750         it before using it for subsequent requests.
    746751      </p>
    747       <p id="rfc.section.3.3.p.5">Since origin servers do not always provide explicit expiration times, HTTP caches may assign heuristic expiration times when
     752      <p id="rfc.section.2.3.p.5">Since origin servers do not always provide explicit expiration times, HTTP caches may assign heuristic expiration times when
    748753         they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible
    749754         expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on
    750755         their results.
    751756      </p>
    752       <p id="rfc.section.3.3.p.6">The calculation to determine if a response has expired is:</p>
    753       <div id="rfc.figure.u.4"></div> <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    754 </pre> <p id="rfc.section.3.3.p.8">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;3.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;3.3.2</a>.
    755       </p>
    756       <p id="rfc.section.3.3.p.9">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
    757          with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;4.2.1</a>.
    758       </p>
    759       <p id="rfc.section.3.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    760       </p>
    761       <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
    762       <p id="rfc.section.3.3.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>
     757      <p id="rfc.section.2.3.p.6">The calculation to determine if a response has expired is:</p>
     758      <div id="rfc.figure.u.3"></div> <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
     759</pre> <p id="rfc.section.2.3.p.8">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
     760      </p>
     761      <p id="rfc.section.2.3.p.9">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
     762         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
     763      </p>
     764      <p id="rfc.section.2.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     765      </p>
     766      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
     767      <p id="rfc.section.2.3.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>
    763768      <ul>
    764          <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>) is present, use its value, or
    765          </li>
    766          <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>) is present, use its value, or
    767          </li>
    768          <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;4.3</a>) is present, use its value minus the value of the Date response header, or
    769          </li>
    770          <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Using Heuristic Freshness">Section&nbsp;3.3.1.1</a>.
     769         <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) is present, use its value, or
     770         </li>
     771         <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) is present, use its value, or
     772         </li>
     773         <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header, or
     774         </li>
     775         <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Using Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
    771776         </li>
    772777      </ul>
    773       <p id="rfc.section.3.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
    774       <h4 id="rfc.section.3.3.1.1"><a href="#rfc.section.3.3.1.1">3.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Using Heuristic Freshness</a></h4>
    775       <p id="rfc.section.3.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code of 200, 203, 206, 300, 301 or 410, a
     778      <p id="rfc.section.2.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
     779      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Using Heuristic Freshness</a></h4>
     780      <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code of 200, 203, 206, 300, 301 or 410, a
    776781         heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for other response status codes.
    777782      </p>
    778       <p id="rfc.section.3.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is
     783      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is
    779784         not already present.
    780785      </p>
    781       <p id="rfc.section.3.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
    782       </p>
    783       <p id="rfc.section.3.3.1.1.p.4"> <span class="comment">[rfc.comment.7: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
    784       </p>
    785       <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    786       <p id="rfc.section.3.3.2.p.1">HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The
     786      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
     787      </p>
     788      <p id="rfc.section.2.3.1.1.p.4"> <span class="comment">[rfc.comment.7: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
     789      </p>
     790      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
     791      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The
    787792         Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin
    788793         server. In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the
    789794         path from the origin server, plus the amount of time it has been in transit along network paths.
    790795      </p>
    791       <p id="rfc.section.3.3.2.p.2">When a response is generated from a stored response, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
     796      <p id="rfc.section.2.3.2.p.2">When a response is generated from a stored response, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
    792797         the algorithm described in this section.
    793798      </p>
    794       <p id="rfc.section.3.3.2.p.3">The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operations.</p>
    795       <p id="rfc.section.3.3.2.p.4">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
    796          was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
    797       </p>
    798       <p id="rfc.section.3.3.2.p.5">The term "now" means "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially
     799      <p id="rfc.section.2.3.2.p.3">The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operations.</p>
     800      <p id="rfc.section.2.3.2.p.4">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
     801         was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
     802      </p>
     803      <p id="rfc.section.2.3.2.p.5">The term "now" means "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially
    799804         hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a> or some similar protocol to synchronize their clocks to a globally accurate time standard.
    800805      </p>
    801       <p id="rfc.section.3.3.2.p.6">A response's age can be calculated in two entirely independent ways: </p>
     806      <p id="rfc.section.2.3.2.p.6">A response's age can be calculated in two entirely independent ways: </p>
    802807      <ol>
    803808         <li>now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative,
     
    806811         <li>age_value, if all of the caches along the response path implement HTTP/1.1.</li>
    807812      </ol>
    808       <p id="rfc.section.3.3.2.p.7">These are combined as</p>
    809       <div id="rfc.figure.u.5"></div> <pre class="text">    corrected_received_age = max(now - date_value, age_value)
    810 </pre> <p id="rfc.section.3.3.2.p.9">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
    811       </p>
    812       <div id="rfc.figure.u.6"></div> <pre class="text">   corrected_initial_age = corrected_received_age
     813      <p id="rfc.section.2.3.2.p.7">These are combined as</p>
     814      <div id="rfc.figure.u.4"></div> <pre class="text">    corrected_received_age = max(now - date_value, age_value)
     815</pre> <p id="rfc.section.2.3.2.p.9">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
     816      </p>
     817      <div id="rfc.figure.u.5"></div> <pre class="text">   corrected_initial_age = corrected_received_age
    813818                         + (now - request_time)
    814 </pre> <p id="rfc.section.3.3.2.p.11">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
    815       <p id="rfc.section.3.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
     819</pre> <p id="rfc.section.2.3.2.p.11">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
     820      <p id="rfc.section.2.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
    816821         was last validated by the origin server to the corrected_initial_age.
    817822      </p>
    818       <p id="rfc.section.3.3.2.p.13">In summary:</p>
    819       <div id="rfc.figure.u.7"></div> <pre class="text">   /*
     823      <p id="rfc.section.2.3.2.p.13">In summary:</p>
     824      <div id="rfc.figure.u.6"></div> <pre class="text">   /*
    820825    * age_value
    821826    *      is the value of Age: header received by the cache with
     
    839844   resident_time = now - response_time;
    840845   current_age   = corrected_initial_age + resident_time;
    841 </pre> <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
    842       <p id="rfc.section.3.3.3.p.1">A "stale" response is one that either has explicit expiry information, or is allowed to have heuristic expiry calculated,
    843          but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a>.
    844       </p>
    845       <p id="rfc.section.3.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     846</pre> <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
     847      <p id="rfc.section.2.3.3.p.1">A "stale" response is one that either has explicit expiry information, or is allowed to have heuristic expiry calculated,
     848         but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>.
     849      </p>
     850      <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    846851         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    847          see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>).
    848       </p>
    849       <p id="rfc.section.3.3.3.p.3">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;4.2.1</a>).
    850       </p>
    851       <p id="rfc.section.3.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
    852       </p>
    853       <p id="rfc.section.3.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;4.6</a>).
    854       </p>
    855       <p id="rfc.section.3.3.3.p.6">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
     852         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
     853      </p>
     854      <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
     855      </p>
     856      <p id="rfc.section.2.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
     857      </p>
     858      <p id="rfc.section.2.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>).
     859      </p>
     860      <p id="rfc.section.2.3.3.p.6">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
    856861         forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
    857862      </p>
    858       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
    859       <p id="rfc.section.3.4.p.1">When a cache has a stale response that it would like to use, it <em class="bcp14">SHOULD</em> first check with the origin server (or possibly an intermediate cache with a fresh response) to see if it is still usable.
     863      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
     864      <p id="rfc.section.2.4.p.1">When a cache has a stale response that it would like to use, it <em class="bcp14">SHOULD</em> first check with the origin server (or possibly an intermediate cache with a fresh response) to see if it is still usable.
    860865         This is called "validating" or "revalidating" the stored response.
    861866      </p>
    862       <p id="rfc.section.3.4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the stored response is valid. When a stored response includes
     867      <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the stored response is valid. When a stored response includes
    863868         one or more "cache validators", such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state
    864869         of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the
     
    867872         be satisfied and the stored response supplanted without the need for an additional network round-trip.
    868873      </p>
    869       <p id="rfc.section.3.4.p.3">See <a href="#combining.headers" title="Combining Responses">Section&nbsp;3.7</a> regarding combining cached headers with those in a 304 response.
    870       </p>
    871       <p id="rfc.section.3.4.p.4">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the stored response includes the "must-revalidate" cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>).
    872       </p>
    873       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
    874       <p id="rfc.section.3.5.p.1">Because unsafe methods <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> have the potential for changing state on the origin server, intervening caches have the opportunity to use them to keep their
     874      <p id="rfc.section.2.4.p.3">See <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a> regarding combining cached headers with those in a 304 response.
     875      </p>
     876      <p id="rfc.section.2.4.p.4">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the stored response includes the "must-revalidate" cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
     877      </p>
     878      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
     879      <p id="rfc.section.2.5.p.1">Because unsafe methods <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> have the potential for changing state on the origin server, intervening caches have the opportunity to use them to keep their
    875880         contents up-to-date.
    876881      </p>
    877       <p id="rfc.section.3.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present):
     882      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present):
    878883      </p>
    879884      <ul>
     
    882887         <li>POST</li>
    883888      </ul>
    884       <p id="rfc.section.3.5.p.3">An invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service
     889      <p id="rfc.section.2.5.p.3">An invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service
    885890         attacks.
    886891      </p>
    887       <p id="rfc.section.3.5.p.4"> <span class="comment">[rfc.comment.8: TODO: "host part" needs to be specified better.]</span>
    888       </p>
    889       <p id="rfc.section.3.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
    890       </p>
    891       <p id="rfc.section.3.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Request-URI, or will mark these
     892      <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment.8: TODO: "host part" needs to be specified better.]</span>
     893      </p>
     894      <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
     895      </p>
     896      <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Request-URI, or will mark these
    892897         as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
    893898      </p>
    894       <p id="rfc.section.3.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
     899      <p id="rfc.section.2.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
    895900         change at the origin server might not have gone through the cache where a response is stored.
    896901      </p>
    897       <p id="rfc.section.3.5.p.8"> <span class="comment">[rfc.comment.9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    898       </p>
    899       <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    900       <p id="rfc.section.3.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;4.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
    901       </p>
    902       <p id="rfc.section.3.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field,
     902      <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment.9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     903      </p>
     904      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
     905      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
     906      </p>
     907      <p id="rfc.section.2.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field,
    903908         it <em class="bcp14">MUST NOT</em> use it to satisfy the request unless all of the selecting request-headers present in the new request match the corresponding
    904909         stored request-headers from the original request.
    905910      </p>
    906       <p id="rfc.section.3.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
     911      <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    907912         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.10: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    908          name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    909       </p>
    910       <p id="rfc.section.3.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests on that resource can only be properly interpreted
     913         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     914      </p>
     915      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests on that resource can only be properly interpreted
    911916         by the origin server.
    912917      </p>
    913       <p id="rfc.section.3.6.p.5">If the selecting request header fields for the stored response do not match the selecting request header fields of the new
     918      <p id="rfc.section.2.6.p.5">If the selecting request header fields for the stored response do not match the selecting request header fields of the new
    914919         request, then the cache <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless it first relays the new request to the origin server in a conditional
    915920         request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity
    916921         to be used.
    917922      </p>
    918       <p id="rfc.section.3.6.p.6">If one or more applicable stored response has an entity tag, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include all of these entity tags in an If-None-Match header field. This conveys to the server the set of
     923      <p id="rfc.section.2.6.p.6">If one or more applicable stored response has an entity tag, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include all of these entity tags in an If-None-Match header field. This conveys to the server the set of
    919924         entities currently stored by the cache, so that if any one of these entities matches the requested entity, the server can
    920925         use the ETag header field in its 304 (Not Modified) response to tell the cache which stored response is appropriate. If the
    921926         entity-tag of the new response matches that of an existing stored resopnse, the new response <em class="bcp14">SHOULD</em> be used to update its header fields, and the result <em class="bcp14">MUST</em> be returned to the client.
    922927      </p>
    923       <p id="rfc.section.3.6.p.7">If any of the existing stored responses contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
     928      <p id="rfc.section.2.6.p.7">If any of the existing stored responses contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
    924929         response.
    925930      </p>
    926       <p id="rfc.section.3.6.p.8">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
     931      <p id="rfc.section.2.6.p.8">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
    927932         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
    928933         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.
    929934      </p>
    930       <p id="rfc.section.3.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span>
    931       </p>
    932       <h2 id="rfc.section.3.7"><a href="#rfc.section.3.7">3.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
    933       <p id="rfc.section.3.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response
     935      <p id="rfc.section.2.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span>
     936      </p>
     937      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
     938      <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response
    934939         with the new one, so that the updated response can be sent to the client.
    935940      </p>
    936       <p id="rfc.section.3.7.p.2">If the status code is 304 (Not Modified), the cache <em class="bcp14">SHOULD</em> use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified
     941      <p id="rfc.section.2.7.p.2">If the status code is 304 (Not Modified), the cache <em class="bcp14">SHOULD</em> use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified
    937942         headers match exactly, the cache <em class="bcp14">MAY</em> combine the stored entity-body in the stored response with the updated entity-body received in the response and use the result
    938943         as the updated entity-body (see <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
    939944      </p>
    940       <p id="rfc.section.3.7.p.3">The stored response headers are used for the updated response, except that </p>
     945      <p id="rfc.section.2.7.p.3">The stored response headers are used for the updated response, except that </p>
    941946      <ul>
    942          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;4.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.
     947         <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.
    943948         </li>
    944949         <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the forwarded response.
     
    947952         </li>
    948953      </ul>
    949       <p id="rfc.section.3.7.p.4">A cache <em class="bcp14">MUST</em> also replace stored headers with corresponding headers received in the incoming response, except for Warning headers as described
     954      <p id="rfc.section.2.7.p.4">A cache <em class="bcp14">MUST</em> also replace stored headers with corresponding headers received in the incoming response, except for Warning headers as described
    950955         immediately above. If a header field-name in the incoming response matches more than one header in the stored response, all
    951956         such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body.
    952957      </p>
    953       <p id="rfc.section.3.7.p.5"><span class="comment">[rfc.comment.12: ISSUE: discuss how to handle HEAD updates]</span></p>
    954       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    955       <p id="rfc.section.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    956       <p id="rfc.section.4.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
     958      <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.12: ISSUE: discuss how to handle HEAD updates]</span></p>
     959      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
     960      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
     961      <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    957962         receives the entity.
    958963      </p>
    959964      <div id="rfc.iref.a.2"></div>
    960965      <div id="rfc.iref.h.2"></div>
    961       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
    962       <p id="rfc.section.4.1.p.1">The Age response-header field conveys the sender's estimate of the amount of time since the response (or its validation) was
    963          generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;3.3.2</a>.
    964       </p>
    965       <div id="rfc.figure.u.8"></div> <pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a> = "Age" ":" <a href="#header.age" class="smpl">age-value</a>
    966   <a href="#header.age" class="smpl">age-value</a> = <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    967 </pre> <div id="rule.delta-seconds">
    968          <p id="rfc.section.4.1.p.3">  Age field-values are non-negative decimal integers, representing time in seconds.</p>
     966      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
     967      <p id="rfc.section.3.1.p.1">The response-header field "Age" conveys the sender's estimate of the amount of time since the response (or its validation)
     968         was generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
     969      </p>
     970      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a>   = "Age" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.age" class="smpl">Age-v</a>
     971  <a href="#header.age" class="smpl">Age-v</a> = <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
     972</pre><div id="rule.delta-seconds">
     973         <p id="rfc.section.3.1.p.3">  Age field-values are non-negative decimal integers, representing time in seconds.</p>
    969974      </div>
    970       <div id="rfc.figure.u.9"></div> <pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    971 </pre> <p id="rfc.section.4.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
     975      <div id="rfc.figure.u.8"></div> <pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
     976</pre> <p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
    972977         it <em class="bcp14">MUST</em> transmit an Age header with a field-value of 2147483648 (2<sup>31</sup>). Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
    973978      </p>
    974       <p id="rfc.section.4.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
     979      <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
    975980         true, since HTTP/1.0 caches may not implement the Age header field.
    976981      </p>
    977982      <div id="rfc.iref.c.3"></div>
    978983      <div id="rfc.iref.h.3"></div>
    979       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    980       <p id="rfc.section.4.2.p.1">The Cache-Control general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
     984      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
     985      <p id="rfc.section.3.2.p.1">The general-header field "Cache-Control" is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
    981986         adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive
    982987         in a request does not imply that the same directive is to be given in the response.
    983988      </p>
    984989      <dl class="empty">
    985          <dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;4.4</a>).
    986          </dd>
    987       </dl>
    988       <p id="rfc.section.4.2.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives
     990         <dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;3.4</a>).
     991         </dd>
     992      </dl>
     993      <p id="rfc.section.3.2.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives
    989994         might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific
    990995         cache.
    991996      </p>
    992       <div id="rfc.figure.u.10"></div> <pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.cache-control" class="smpl">Cache-Control</a>   = "Cache-Control" ":" 1#<a href="#header.cache-control" class="smpl">cache-directive</a>
     997      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.cache-control" class="smpl">Cache-Control</a>   = "Cache-Control" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.cache-control" class="smpl">Cache-Control-v</a>
     998  <a href="#header.cache-control" class="smpl">Cache-Control-v</a> = 1#<a href="#header.cache-control" class="smpl">cache-directive</a>
    993999
    994   <a href="#header.cache-control" class="smpl">cache-directive</a> = <a href="#cache-request-directive" class="smpl">cache-request-directive</a>
    995      / <a href="#cache-response-directive" class="smpl">cache-response-directive</a>
     1000  <a href="#header.cache-control" class="smpl">cache-directive</a> = <a href="#header.cache-control" class="smpl">cache-request-directive</a>
     1001     / <a href="#header.cache-control" class="smpl">cache-response-directive</a>
    9961002
    997   <a href="#header.cache-control" class="smpl">cache-extension</a> = <a href="#notation" class="smpl">token</a> [ "=" ( <a href="#notation" class="smpl">token</a> / <a href="#notation" class="smpl">quoted-string</a> ) ]
    998 </pre> <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
    999       <div id="rfc.figure.u.11"></div> <pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#cache-request-directive" class="smpl">cache-request-directive</a> =
     1003  <a href="#header.cache-control" class="smpl">cache-extension</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
     1004</pre><h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
     1005      <div id="rfc.figure.u.10"></div> <pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.cache-control" class="smpl">cache-request-directive</a> =
    10001006       "no-cache"
    10011007     / "no-store"
     
    10061012     / "only-if-cached"
    10071013     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    1008 </pre> <p id="rfc.section.4.2.1.p.2"> <span id="rfc.iref.c.4"></span>  <span id="rfc.iref.n.1"></span> no-cache
     1014</pre> <p id="rfc.section.3.2.1.p.2"> <span id="rfc.iref.c.4"></span>  <span id="rfc.iref.n.1"></span> no-cache
    10091015      </p>
    10101016      <dl class="empty">
     
    10121018         </dd>
    10131019      </dl>
    1014       <p id="rfc.section.4.2.1.p.3"> <span id="rfc.iref.c.5"></span>  <span id="rfc.iref.n.2"></span> no-store
     1020      <p id="rfc.section.3.2.1.p.3"> <span id="rfc.iref.c.5"></span>  <span id="rfc.iref.n.2"></span> no-store
    10151021      </p>
    10161022      <dl class="empty">
     
    10221028         </dd>
    10231029      </dl>
    1024       <p id="rfc.section.4.2.1.p.4"> <span id="rfc.iref.c.6"></span>  <span id="rfc.iref.m.1"></span> max-age
     1030      <p id="rfc.section.3.2.1.p.4"> <span id="rfc.iref.c.6"></span>  <span id="rfc.iref.m.1"></span> max-age
    10251031      </p>
    10261032      <dl class="empty">
     
    10291035         </dd>
    10301036      </dl>
    1031       <p id="rfc.section.4.2.1.p.5"> <span id="rfc.iref.c.7"></span>  <span id="rfc.iref.m.2"></span> max-stale
     1037      <p id="rfc.section.3.2.1.p.5"> <span id="rfc.iref.c.7"></span>  <span id="rfc.iref.m.2"></span> max-stale
    10321038      </p>
    10331039      <dl class="empty">
     
    10381044         </dd>
    10391045      </dl>
    1040       <p id="rfc.section.4.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh
     1046      <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh
    10411047      </p>
    10421048      <dl class="empty">
     
    10461052         </dd>
    10471053      </dl>
    1048       <p id="rfc.section.4.2.1.p.7"> <span id="rfc.iref.c.9"></span>  <span id="rfc.iref.n.3"></span> no-transform
     1054      <p id="rfc.section.3.2.1.p.7"> <span id="rfc.iref.c.9"></span>  <span id="rfc.iref.n.3"></span> no-transform
    10491055      </p>
    10501056      <dl class="empty">
     
    10521058         </dd>
    10531059      </dl>
    1054       <p id="rfc.section.4.2.1.p.8"> <span id="rfc.iref.c.10"></span>  <span id="rfc.iref.o.1"></span> only-if-cached
     1060      <p id="rfc.section.3.2.1.p.8"> <span id="rfc.iref.c.10"></span>  <span id="rfc.iref.o.1"></span> only-if-cached
    10551061      </p>
    10561062      <dl class="empty">
     
    10611067         </dd>
    10621068      </dl>
    1063       <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
    1064       <div id="rfc.figure.u.12"></div> <pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#cache-response-directive" class="smpl">cache-response-directive</a> =
     1069      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
     1070      <div id="rfc.figure.u.11"></div> <pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.cache-control" class="smpl">cache-response-directive</a> =
    10651071       "public"
    10661072     / "private" [ "=" <a href="#notation" class="smpl">DQUOTE</a> 1#<a href="#abnf.dependencies" class="smpl">field-name</a> <a href="#notation" class="smpl">DQUOTE</a> ]
     
    10731079     / "s-maxage" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    10741080     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    1075 </pre> <p id="rfc.section.4.2.2.p.2"> <span id="rfc.iref.c.11"></span>  <span id="rfc.iref.p.1"></span> public
     1081</pre> <p id="rfc.section.3.2.2.p.2"> <span id="rfc.iref.c.11"></span>  <span id="rfc.iref.p.1"></span> public
    10761082      </p>
    10771083      <dl class="empty">
     
    10791085         </dd>
    10801086      </dl>
    1081       <p id="rfc.section.4.2.2.p.3"> <span id="rfc.iref.c.12"></span>  <span id="rfc.iref.p.2"></span> private
     1087      <p id="rfc.section.3.2.2.p.3"> <span id="rfc.iref.c.12"></span>  <span id="rfc.iref.p.2"></span> private
    10821088      </p>
    10831089      <dl class="empty">
     
    10911097         </dd>
    10921098      </dl>
    1093       <p id="rfc.section.4.2.2.p.4"> <span id="rfc.iref.c.13"></span>  <span id="rfc.iref.n.4"></span> no-cache
     1099      <p id="rfc.section.3.2.2.p.4"> <span id="rfc.iref.c.13"></span>  <span id="rfc.iref.n.4"></span> no-cache
    10941100      </p>
    10951101      <dl class="empty">
     
    11041110         </dd>
    11051111      </dl>
    1106       <p id="rfc.section.4.2.2.p.5"> <span id="rfc.iref.c.14"></span>  <span id="rfc.iref.n.5"></span> no-store
     1112      <p id="rfc.section.3.2.2.p.5"> <span id="rfc.iref.c.14"></span>  <span id="rfc.iref.n.5"></span> no-store
    11071113      </p>
    11081114      <dl class="empty">
     
    11131119         </dd>
    11141120      </dl>
    1115       <p id="rfc.section.4.2.2.p.6"> <span id="rfc.iref.c.15"></span>  <span id="rfc.iref.m.4"></span> must-revalidate
     1121      <p id="rfc.section.3.2.2.p.6"> <span id="rfc.iref.c.15"></span>  <span id="rfc.iref.m.4"></span> must-revalidate
    11161122      </p>
    11171123      <dl class="empty">
     
    11281134         </dd>
    11291135      </dl>
    1130       <p id="rfc.section.4.2.2.p.7"> <span id="rfc.iref.c.16"></span>  <span id="rfc.iref.p.3"></span> proxy-revalidate
     1136      <p id="rfc.section.3.2.2.p.7"> <span id="rfc.iref.c.16"></span>  <span id="rfc.iref.p.3"></span> proxy-revalidate
    11311137      </p>
    11321138      <dl class="empty">
     
    11351141         </dd>
    11361142      </dl>
    1137       <p id="rfc.section.4.2.2.p.8"> <span id="rfc.iref.c.17"></span>  <span id="rfc.iref.m.5"></span> max-age
     1143      <p id="rfc.section.3.2.2.p.8"> <span id="rfc.iref.c.17"></span>  <span id="rfc.iref.m.5"></span> max-age
    11381144      </p>
    11391145      <dl class="empty">
     
    11421148         </dd>
    11431149      </dl>
    1144       <p id="rfc.section.4.2.2.p.9"> <span id="rfc.iref.c.18"></span>  <span id="rfc.iref.s.2"></span> s-maxage
     1150      <p id="rfc.section.3.2.2.p.9"> <span id="rfc.iref.c.18"></span>  <span id="rfc.iref.s.2"></span> s-maxage
    11451151      </p>
    11461152      <dl class="empty">
     
    11501156         </dd>
    11511157      </dl>
    1152       <p id="rfc.section.4.2.2.p.10"> <span id="rfc.iref.c.19"></span>  <span id="rfc.iref.n.6"></span> no-transform
     1158      <p id="rfc.section.3.2.2.p.10"> <span id="rfc.iref.c.19"></span>  <span id="rfc.iref.n.6"></span> no-transform
    11531159      </p>
    11541160      <dl class="empty">
     
    11561162         </dd>
    11571163      </dl>
    1158       <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
    1159       <p id="rfc.section.4.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
     1164      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
     1165      <p id="rfc.section.3.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
    11601166         value. Informational extensions (those which do not require a change in cache behavior) <em class="bcp14">MAY</em> be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers
    11611167         to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications
     
    11641170         way, extensions to the cache-control directives can be made without requiring changes to the base protocol.
    11651171      </p>
    1166       <p id="rfc.section.4.2.3.p.2">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
     1172      <p id="rfc.section.3.2.3.p.2">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
    11671173         obeying certain extensions, and ignoring all directives that it does not understand.
    11681174      </p>
    1169       <p id="rfc.section.4.2.3.p.3">For example, consider a hypothetical new response directive called "community" which acts as a modifier to the private directive.
     1175      <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" which acts as a modifier to the private directive.
    11701176         We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members
    11711177         of the community named within its value may cache the response. An origin server wishing to allow the UCI community to use
    11721178         an otherwise private response in their shared cache(s) could do so by including
    11731179      </p>
    1174       <div id="rfc.figure.u.13"></div> <pre class="text">    Cache-Control: private, community="UCI"
    1175 </pre> <p id="rfc.section.4.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
     1180      <div id="rfc.figure.u.12"></div> <pre class="text">    Cache-Control: private, community="UCI"
     1181</pre> <p id="rfc.section.3.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
    11761182         it will also see and understand the private directive and thus default to the safe behavior.
    11771183      </p>
    1178       <p id="rfc.section.4.2.3.p.6">Unrecognized cache directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard
     1184      <p id="rfc.section.3.2.3.p.6">Unrecognized cache directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard
    11791185         directives (or the response's default cacheability) such that the cache behavior will remain minimally correct even if the
    11801186         cache does not understand the extension(s).
     
    11821188      <div id="rfc.iref.e.2"></div>
    11831189      <div id="rfc.iref.h.4"></div>
    1184       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
    1185       <p id="rfc.section.4.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;3.3</a> for further discussion of the expiration model.
    1186       </p>
    1187       <p id="rfc.section.4.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
     1190      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
     1191      <p id="rfc.section.3.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the expiration model.
     1192      </p>
     1193      <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
    11881194         that time.
    11891195      </p>
    1190       <p id="rfc.section.4.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    1191       </p>
    1192       <div id="rfc.figure.u.14"></div> <pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.expires" class="smpl">Expires</a> = "Expires" ":" <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    1193 </pre> <p id="rfc.section.4.3.p.5">For example</p>
    1194       <div id="rfc.figure.u.15"></div> <pre class="text">   Expires: Thu, 01 Dec 1994 16:00:00 GMT
    1195 </pre> <p id="rfc.section.4.3.p.7"> </p>
    1196       <dl class="empty">
    1197          <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>), that directive overrides the Expires field.
    1198          </dd>
    1199       </dl>
    1200       <p id="rfc.section.4.3.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
    1201       </p>
    1202       <p id="rfc.section.4.3.p.9">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
     1196      <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     1197      </p>
     1198      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.expires" class="smpl">Expires</a>   = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a>
     1199  <a href="#header.expires" class="smpl">Expires-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
     1200</pre><p id="rfc.section.3.3.p.5">For example</p>
     1201      <div id="rfc.figure.u.14"></div> <pre class="text">   Expires: Thu, 01 Dec 1994 16:00:00 GMT
     1202</pre> <p id="rfc.section.3.3.p.7"> </p>
     1203      <dl class="empty">
     1204         <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field.
     1205         </dd>
     1206      </dl>
     1207      <p id="rfc.section.3.3.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
     1208      </p>
     1209      <p id="rfc.section.3.3.p.9">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
    12031210      </p>
    12041211      <div id="rfc.iref.p.4"></div>
    12051212      <div id="rfc.iref.h.5"></div>
    1206       <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
    1207       <p id="rfc.section.4.4.p.1">The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along
    1208          the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some
    1209          systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives.
    1210       </p>
    1211       <div id="rfc.figure.u.16"></div> <pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#header.pragma" class="smpl">Pragma</a>            = "Pragma" ":" 1#<a href="#header.pragma" class="smpl">pragma-directive</a>
     1213      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
     1214      <p id="rfc.section.3.4.p.1">The general-header field "Pragma" is used to include implementation-specific directives that might apply to any recipient
     1215         along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however,
     1216         some systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives.
     1217      </p>
     1218      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.pragma" class="smpl">Pragma</a>            = "Pragma" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.pragma" class="smpl">Pragma-v</a>
     1219  <a href="#header.pragma" class="smpl">Pragma-v</a>          = 1#<a href="#header.pragma" class="smpl">pragma-directive</a>
    12121220  <a href="#header.pragma" class="smpl">pragma-directive</a>  = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
    1213   <a href="#header.pragma" class="smpl">extension-pragma</a>  = <a href="#notation" class="smpl">token</a> [ "=" ( <a href="#notation" class="smpl">token</a> / <a href="#notation" class="smpl">quoted-string</a> ) ]
    1214 </pre> <p id="rfc.section.4.4.p.3">When the no-cache directive is present in a request message, an application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive
    1215          has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".
    1216       </p>
    1217       <p id="rfc.section.4.4.p.4"> </p>
     1221  <a href="#header.pragma" class="smpl">extension-pragma</a>  = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
     1222</pre><p id="rfc.section.3.4.p.3">When the no-cache directive is present in a request message, an application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive
     1223         has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".
     1224      </p>
     1225      <p id="rfc.section.3.4.p.4"> </p>
    12181226      <dl class="empty">
    12191227         <dd> <b>Note:</b> because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable
     
    12211229         </dd>
    12221230      </dl>
    1223       <p id="rfc.section.4.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p>
     1231      <p id="rfc.section.3.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p>
    12241232      <div id="rfc.iref.v.3"></div>
    12251233      <div id="rfc.iref.h.6"></div>
    1226       <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
    1227       <p id="rfc.section.4.5.p.1">The Vary response-header field's value indicates the set of request-header fields that fully determines, while the response
     1234      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
     1235      <p id="rfc.section.3.5.p.1">The "Vary" response-header field's value indicates the set of request-header fields that fully determines, while the response
    12281236         is fresh, whether a cache is permitted to use the response to reply to a subsequent request without validation. For uncacheable
    12291237         or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation.
    12301238         A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this
    1231          response is the appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;3.6</a> for use of the Vary header field by caches.
    1232       </p>
    1233       <div id="rfc.figure.u.17"></div> <pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#header.vary" class="smpl">Vary</a>  = "Vary" ":" ( "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a> )
    1234 </pre> <p id="rfc.section.4.5.p.3">The set of header fields named by the Vary field value is known as the "selecting" request-headers.</p>
    1235       <p id="rfc.section.4.5.p.4">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
     1239         response is the appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a> for use of the Vary header field by caches.
     1240      </p>
     1241      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span>  <a href="#header.vary" class="smpl">Vary</a>   = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a>
     1242  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
     1243</pre><p id="rfc.section.3.5.p.3">The set of header fields named by the Vary field value is known as the "selecting" request-headers.</p>
     1244      <p id="rfc.section.3.5.p.4">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
    12361245         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    12371246         resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide
    12381247         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    12391248      </p>
    1240       <p id="rfc.section.4.5.p.5">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
     1249      <p id="rfc.section.3.5.p.5">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
    12411250         of the client), play a role in the selection of the response representation. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server.
    12421251      </p>
    1243       <p id="rfc.section.4.5.p.6">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
     1252      <p id="rfc.section.3.5.p.6">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
    12441253         are case-insensitive.
    12451254      </p>
    12461255      <div id="rfc.iref.w.1"></div>
    12471256      <div id="rfc.iref.h.7"></div>
    1248       <h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
    1249       <p id="rfc.section.4.6.p.1">The Warning general-header field is used to carry additional information about the status or transformation of a message which
    1250          might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
     1257      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
     1258      <p id="rfc.section.3.6.p.1">The general-header field "Warning" is used to carry additional information about the status or transformation of a message
     1259         which might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
    12511260         by caching operations or transformations applied to the entity body of the message.
    12521261      </p>
    1253       <p id="rfc.section.4.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
     1262      <p id="rfc.section.3.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
    12541263         code, distinguish these responses from true failures.
    12551264      </p>
    1256       <p id="rfc.section.4.6.p.3">Warning headers can in general be applied to any message, however some warn-codes are specific to caches and can only be applied
     1265      <p id="rfc.section.3.6.p.3">Warning headers can in general be applied to any message, however some warn-codes are specific to caches and can only be applied
    12571266         to response messages.
    12581267      </p>
    1259       <div id="rfc.figure.u.18"></div> <pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.warning" class="smpl">Warning</a>    = "Warning" ":" 1#<a href="#header.warning" class="smpl">warning-value</a>
     1268      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.warning" class="smpl">Warning</a>    = "Warning" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.warning" class="smpl">Warning-v</a>
     1269  <a href="#header.warning" class="smpl">Warning-v</a>  = 1#<a href="#header.warning" class="smpl">warning-value</a>
    12601270 
    12611271  <a href="#header.warning" class="smpl">warning-value</a> = <a href="#header.warning" class="smpl">warn-code</a> <a href="#notation" class="smpl">SP</a> <a href="#header.warning" class="smpl">warn-agent</a> <a href="#notation" class="smpl">SP</a> <a href="#header.warning" class="smpl">warn-text</a>
     
    12661276                  ; the name or pseudonym of the server adding
    12671277                  ; the Warning header, for use in debugging
    1268   <a href="#header.warning" class="smpl">warn-text</a>  = <a href="#notation" class="smpl">quoted-string</a>
     1278  <a href="#header.warning" class="smpl">warn-text</a>  = <a href="#core.rules" class="smpl">quoted-string</a>
    12691279  <a href="#header.warning" class="smpl">warn-date</a>  = <a href="#notation" class="smpl">DQUOTE</a> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> <a href="#notation" class="smpl">DQUOTE</a>
    1270 </pre> <p id="rfc.section.4.6.p.5">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number.
     1280</pre><p id="rfc.section.3.6.p.5">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number.
    12711281         For example, a server might provide the same warning with texts in both English and Basque.
    12721282      </p>
    1273       <p id="rfc.section.4.6.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response. If it is not possible to inform
     1283      <p id="rfc.section.3.6.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response. If it is not possible to inform
    12741284         the user of all of the warnings, the user agent <em class="bcp14">SHOULD</em> follow these heuristics:
    12751285      </p>
     
    12801290         </li>
    12811291      </ul>
    1282       <p id="rfc.section.4.6.p.7">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers.
    1283       </p>
    1284       <p id="rfc.section.4.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
     1292      <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers.
     1293      </p>
     1294      <p id="rfc.section.3.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
    12851295         a stored response after validation:
    12861296      </p>
     
    12921302         </li>
    12931303      </ul>
    1294       <p id="rfc.section.4.6.p.9">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response.
     1304      <p id="rfc.section.3.6.p.9">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response.
    12951305         This decision can be based on any available knowledge, such as the location of the cache or user, the Accept-Language field
    12961306         in a request, the Content-Language field in a response, etc. The default language is English and the default character set
    12971307         is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>).
    12981308      </p>
    1299       <p id="rfc.section.4.6.p.10">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
    1300       </p>
    1301       <p id="rfc.section.4.6.p.11">If an implementation sends a message with one or more Warning headers to a receiver whose version is HTTP/1.0 or lower, then
     1309      <p id="rfc.section.3.6.p.10">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
     1310      </p>
     1311      <p id="rfc.section.3.6.p.11">If an implementation sends a message with one or more Warning headers to a receiver whose version is HTTP/1.0 or lower, then
    13021312         the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header in the message.
    13031313      </p>
    1304       <p id="rfc.section.4.6.p.12">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from
     1314      <p id="rfc.section.3.6.p.12">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from
    13051315         the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
    13061316         header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well.
    13071317      </p>
    1308       <p id="rfc.section.4.6.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
     1318      <p id="rfc.section.3.6.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
    13091319         of its meaning.
    13101320      </p>
    1311       <p id="rfc.section.4.6.p.14">110 Response is stale </p>
     1321      <p id="rfc.section.3.6.p.14">110 Response is stale </p>
    13121322      <dl class="empty">
    13131323         <dd><em class="bcp14">SHOULD</em> be included whenever the returned response is stale.
    13141324         </dd>
    13151325      </dl>
    1316       <p id="rfc.section.4.6.p.15">111 Revalidation failed </p>
     1326      <p id="rfc.section.3.6.p.15">111 Revalidation failed </p>
    13171327      <dl class="empty">
    13181328         <dd><em class="bcp14">SHOULD</em> be included if a cache returns a stale response because an attempt to validate the response failed, due to an inability to
     
    13201330         </dd>
    13211331      </dl>
    1322       <p id="rfc.section.4.6.p.16">112 Disconnected operation </p>
     1332      <p id="rfc.section.3.6.p.16">112 Disconnected operation </p>
    13231333      <dl class="empty">
    13241334         <dd><em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time.
    13251335         </dd>
    13261336      </dl>
    1327       <p id="rfc.section.4.6.p.17">113 Heuristic expiration </p>
     1337      <p id="rfc.section.3.6.p.17">113 Heuristic expiration </p>
    13281338      <dl class="empty">
    13291339         <dd><em class="bcp14">SHOULD</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater
     
    13311341         </dd>
    13321342      </dl>
    1333       <p id="rfc.section.4.6.p.18">199 Miscellaneous warning </p>
     1343      <p id="rfc.section.3.6.p.18">199 Miscellaneous warning </p>
    13341344      <dl class="empty">
    13351345         <dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.
    13361346         </dd>
    13371347      </dl>
    1338       <p id="rfc.section.4.6.p.19">214 Transformation applied </p>
     1348      <p id="rfc.section.3.6.p.19">214 Transformation applied </p>
    13391349      <dl class="empty">
    13401350         <dd><em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the
     
    13431353         </dd>
    13441354      </dl>
    1345       <p id="rfc.section.4.6.p.20">299 Miscellaneous persistent warning </p>
     1355      <p id="rfc.section.3.6.p.20">299 Miscellaneous persistent warning </p>
    13461356      <dl class="empty">
    13471357         <dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.
    13481358         </dd>
    13491359      </dl>
    1350       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
    1351       <p id="rfc.section.5.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity
     1360      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
     1361      <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity
    13521362         retrieved earlier in a session.
    13531363      </p>
    1354       <p id="rfc.section.5.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a correct view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the
     1364      <p id="rfc.section.4.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a correct view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the
    13551365         user saw at the time when the resource was retrieved.
    13561366      </p>
    1357       <p id="rfc.section.5.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history
     1367      <p id="rfc.section.4.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history
    13581368         documents.
    13591369      </p>
    1360       <p id="rfc.section.5.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>
     1370      <p id="rfc.section.4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>
    13611371      <dl class="empty">
    13621372         <dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
     
    13681378         </dd>
    13691379      </dl>
    1370       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    1371       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2>
    1372       <p id="rfc.section.6.1.p.1">The Message Header Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1380      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     1381      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2>
     1382      <p id="rfc.section.5.1.p.1">The Message Header Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    13731383      </p>
    13741384      <div id="rfc.table.1">
     
    13881398                  <td>http</td>
    13891399                  <td>standard</td>
    1390                   <td> <a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;4.1</a>
     1400                  <td> <a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>
    13911401                  </td>
    13921402               </tr>
     
    13951405                  <td>http</td>
    13961406                  <td>standard</td>
    1397                   <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;4.2</a>
     1407                  <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a>
    13981408                  </td>
    13991409               </tr>
     
    14021412                  <td>http</td>
    14031413                  <td>standard</td>
    1404                   <td> <a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;4.3</a>
     1414                  <td> <a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>
    14051415                  </td>
    14061416               </tr>
     
    14091419                  <td>http</td>
    14101420                  <td>standard</td>
    1411                   <td> <a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;4.4</a>
     1421                  <td> <a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;3.4</a>
    14121422                  </td>
    14131423               </tr>
     
    14161426                  <td>http</td>
    14171427                  <td>standard</td>
    1418                   <td> <a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;4.5</a>
     1428                  <td> <a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;3.5</a>
    14191429                  </td>
    14201430               </tr>
     
    14231433                  <td>http</td>
    14241434                  <td>standard</td>
    1425                   <td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;4.6</a>
     1435                  <td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>
    14261436                  </td>
    14271437               </tr>
     
    14291439         </table>
    14301440      </div>
    1431       <p id="rfc.section.6.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    1432       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1433       <p id="rfc.section.7.p.1">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
     1441      <p id="rfc.section.5.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     1442      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     1443      <p id="rfc.section.6.p.1">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
    14341444         exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information
    14351445         long after a user believes that the information has been removed from the network. Therefore, cache contents should be protected
    14361446         as sensitive information.
    14371447      </p>
    1438       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    1439       <p id="rfc.section.8.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including:
     1448      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
     1449      <p id="rfc.section.7.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including:
    14401450         Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
    14411451      </p>
    1442       <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
     1452      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    14431453      </h1>
    1444       <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References
     1454      <h2 id="rfc.references.1"><a href="#rfc.section.8.1" id="rfc.section.8.1">8.1</a> Normative References
    14451455      </h2>
    1446       <table summary="Normative References">                 
     1456      <table summary="Normative References">                   
    14471457         <tr>
    14481458            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
     
    14921502            </td>
    14931503         </tr>
     1504         <tr>
     1505            <td class="reference"><b id="RFC5234">[RFC5234]</b></td>
     1506            <td class="top"><a title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.
     1507            </td>
     1508         </tr>
    14941509      </table>
    1495       <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References
     1510      <h2 id="rfc.references.2"><a href="#rfc.section.8.2" id="rfc.section.8.2">8.2</a> Informative References
    14961511      </h2>
    14971512      <table summary="Informative References">     
     
    15301545      <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    15311546      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
    1532       <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">3.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">4.2</a>).
     1547      <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">3.2</a>).
    15331548      </p>
    15341549      <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    15351550         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1536          computed. (see also <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
     1551         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
    15371552      </p>
    15381553      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate.</p>
    15391554      <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send
    1540          needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;3.7</a>)
     1555         needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>)
    15411556      </p>
    15421557      <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p>
    1543       <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">3.3</a>, <a href="#combining.headers" title="Combining Responses">3.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">4.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">4.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
     1558      <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
    15441559      </p>
    15451560      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    1546       <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;3.5</a>)
     1561      <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
    15471562      </p>
    15481563      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
     
    16381653            <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind">
    16391654                  <li class="indline1">age&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.1">1.2</a></li>
    1640                   <li class="indline1">Age header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">3.2</a>, <a class="iref" href="#rfc.iref.a.2"><b>4.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">6.1</a></li>
     1655                  <li class="indline1">Age header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.iref.a.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">5.1</a></li>
    16411656               </ul>
    16421657            </li>
     
    16451660                  <li class="indline1">Cache Directives&nbsp;&nbsp;
    16461661                     <ul class="ind">
    1647                         <li class="indline1">max-age&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.6"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.17"><b>4.2.2</b></a></li>
    1648                         <li class="indline1">max-stale&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7"><b>4.2.1</b></a></li>
    1649                         <li class="indline1">min-fresh&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.8"><b>4.2.1</b></a></li>
    1650                         <li class="indline1">must-revalidate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.15"><b>4.2.2</b></a></li>
    1651                         <li class="indline1">no-cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.13"><b>4.2.2</b></a></li>
    1652                         <li class="indline1">no-store&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.5"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.14"><b>4.2.2</b></a></li>
    1653                         <li class="indline1">no-transform&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.9"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.c.19"><b>4.2.2</b></a></li>
    1654                         <li class="indline1">only-if-cached&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.10"><b>4.2.1</b></a></li>
    1655                         <li class="indline1">private&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.12"><b>4.2.2</b></a></li>
    1656                         <li class="indline1">proxy-revalidate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.16"><b>4.2.2</b></a></li>
    1657                         <li class="indline1">public&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.11"><b>4.2.2</b></a></li>
    1658                         <li class="indline1">s-maxage&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.18"><b>4.2.2</b></a></li>
    1659                      </ul>
    1660                   </li>
    1661                   <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">3.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>4.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">6.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
     1662                        <li class="indline1">max-age&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.6"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.c.17"><b>3.2.2</b></a></li>
     1663                        <li class="indline1">max-stale&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7"><b>3.2.1</b></a></li>
     1664                        <li class="indline1">min-fresh&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.8"><b>3.2.1</b></a></li>
     1665                        <li class="indline1">must-revalidate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.15"><b>3.2.2</b></a></li>
     1666                        <li class="indline1">no-cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.c.13"><b>3.2.2</b></a></li>
     1667                        <li class="indline1">no-store&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.5"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.c.14"><b>3.2.2</b></a></li>
     1668                        <li class="indline1">no-transform&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.9"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.c.19"><b>3.2.2</b></a></li>
     1669                        <li class="indline1">only-if-cached&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.10"><b>3.2.1</b></a></li>
     1670                        <li class="indline1">private&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.12"><b>3.2.2</b></a></li>
     1671                        <li class="indline1">proxy-revalidate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.16"><b>3.2.2</b></a></li>
     1672                        <li class="indline1">public&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.11"><b>3.2.2</b></a></li>
     1673                        <li class="indline1">s-maxage&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.18"><b>3.2.2</b></a></li>
     1674                     </ul>
     1675                  </li>
     1676                  <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
    16621677                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">1.2</a></li>
    16631678               </ul>
    16641679            </li>
    16651680            <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind">
    1666                   <li class="indline1">Expires header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">3.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">3.3.1</a>, <a class="iref" href="#rfc.iref.e.2"><b>4.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">6.1</a></li>
     1681                  <li class="indline1">Expires header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3.1</a>, <a class="iref" href="#rfc.iref.e.2"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">5.1</a></li>
    16671682                  <li class="indline1">explicit expiration time&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1">1.2</a></li>
    16681683               </ul>
     
    16771692                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    16781693                     <ul class="ind">
    1679                         <li class="indline1"><tt>Age</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>4.1</b></a></li>
    1680                         <li class="indline1"><tt>age-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>4.1</b></a></li>
    1681                         <li class="indline1"><tt>Cache-Control</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>4.2</b></a></li>
    1682                         <li class="indline1"><tt>cache-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>4.2</b></a></li>
    1683                         <li class="indline1"><tt>cache-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>4.2</b></a></li>
    1684                         <li class="indline1"><tt>cache-request-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>4.2.1</b></a></li>
    1685                         <li class="indline1"><tt>cache-response-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>4.2.2</b></a></li>
    1686                         <li class="indline1"><tt>delta-seconds</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>4.1</b></a></li>
    1687                         <li class="indline1"><tt>Expires</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>4.3</b></a></li>
    1688                         <li class="indline1"><tt>extension-pragma</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>4.4</b></a></li>
    1689                         <li class="indline1"><tt>Pragma</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>4.4</b></a></li>
    1690                         <li class="indline1"><tt>pragma-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>4.4</b></a></li>
    1691                         <li class="indline1"><tt>Vary</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>4.5</b></a></li>
    1692                         <li class="indline1"><tt>warn-agent</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>4.6</b></a></li>
    1693                         <li class="indline1"><tt>warn-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>4.6</b></a></li>
    1694                         <li class="indline1"><tt>warn-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>4.6</b></a></li>
    1695                         <li class="indline1"><tt>warn-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>4.6</b></a></li>
    1696                         <li class="indline1"><tt>Warning</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>4.6</b></a></li>
    1697                         <li class="indline1"><tt>warning-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>4.6</b></a></li>
     1694                        <li class="indline1"><tt>Age</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>3.1</b></a></li>
     1695                        <li class="indline1"><tt>Age-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>3.1</b></a></li>
     1696                        <li class="indline1"><tt>Cache-Control</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>3.2</b></a></li>
     1697                        <li class="indline1"><tt>Cache-Control-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>3.2</b></a></li>
     1698                        <li class="indline1"><tt>cache-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>3.2</b></a></li>
     1699                        <li class="indline1"><tt>cache-request-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>3.2.1</b></a></li>
     1700                        <li class="indline1"><tt>cache-response-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>3.2.2</b></a></li>
     1701                        <li class="indline1"><tt>delta-seconds</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>3.1</b></a></li>
     1702                        <li class="indline1"><tt>Expires</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>3.3</b></a></li>
     1703                        <li class="indline1"><tt>Expires-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>3.3</b></a></li>
     1704                        <li class="indline1"><tt>extension-pragma</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>3.4</b></a></li>
     1705                        <li class="indline1"><tt>Pragma</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>3.4</b></a></li>
     1706                        <li class="indline1"><tt>pragma-directive</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>3.4</b></a></li>
     1707                        <li class="indline1"><tt>Pragma-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>3.4</b></a></li>
     1708                        <li class="indline1"><tt>Vary</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>3.5</b></a></li>
     1709                        <li class="indline1"><tt>Vary-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>3.5</b></a></li>
     1710                        <li class="indline1"><tt>warn-agent</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>3.6</b></a></li>
     1711                        <li class="indline1"><tt>warn-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>3.6</b></a></li>
     1712                        <li class="indline1"><tt>warn-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>3.6</b></a></li>
     1713                        <li class="indline1"><tt>warn-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>3.6</b></a></li>
     1714                        <li class="indline1"><tt>Warning</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>3.6</b></a></li>
     1715                        <li class="indline1"><tt>Warning-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>3.6</b></a></li>
     1716                        <li class="indline1"><tt>warning-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>3.6</b></a></li>
    16981717                     </ul>
    16991718                  </li>
     
    17031722                  <li class="indline1">Headers&nbsp;&nbsp;
    17041723                     <ul class="ind">
    1705                         <li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">3.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>4.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">6.1</a></li>
    1706                         <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">3.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">3.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>4.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">6.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
    1707                         <li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">3.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">3.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>4.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">6.1</a></li>
    1708                         <li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">3.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">4.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>4.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">6.1</a></li>
    1709                         <li class="indline1">Vary&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">3.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>4.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">6.1</a></li>
    1710                         <li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">3.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>4.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">6.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
     1724                        <li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">5.1</a></li>
     1725                        <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
     1726                        <li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">5.1</a></li>
     1727                        <li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li>
     1728                        <li class="indline1">Vary&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">2.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.1</a></li>
     1729                        <li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
    17111730                     </ul>
    17121731                  </li>
     
    17151734            </li>
    17161735            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    1717                   <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">4.6</a>, <a class="iref" href="#ISO-8859-1"><b>9.1</b></a></li>
     1736                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">3.6</a>, <a class="iref" href="#ISO-8859-1"><b>8.1</b></a></li>
    17181737               </ul>
    17191738            </li>
     
    17211740                  <li class="indline1">max-age&nbsp;&nbsp;
    17221741                     <ul class="ind">
    1723                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.m.5"><b>4.2.2</b></a></li>
     1742                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.m.5"><b>3.2.2</b></a></li>
    17241743                     </ul>
    17251744                  </li>
    17261745                  <li class="indline1">max-stale&nbsp;&nbsp;
    17271746                     <ul class="ind">
    1728                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.2"><b>4.2.1</b></a></li>
     1747                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.2"><b>3.2.1</b></a></li>
    17291748                     </ul>
    17301749                  </li>
    17311750                  <li class="indline1">min-fresh&nbsp;&nbsp;
    17321751                     <ul class="ind">
    1733                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.3"><b>4.2.1</b></a></li>
     1752                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.3"><b>3.2.1</b></a></li>
    17341753                     </ul>
    17351754                  </li>
    17361755                  <li class="indline1">must-revalidate&nbsp;&nbsp;
    17371756                     <ul class="ind">
    1738                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.4"><b>4.2.2</b></a></li>
     1757                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.4"><b>3.2.2</b></a></li>
    17391758                     </ul>
    17401759                  </li>
     
    17441763                  <li class="indline1">no-cache&nbsp;&nbsp;
    17451764                     <ul class="ind">
    1746                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.1"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.n.4"><b>4.2.2</b></a></li>
     1765                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.1"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.n.4"><b>3.2.2</b></a></li>
    17471766                     </ul>
    17481767                  </li>
    17491768                  <li class="indline1">no-store&nbsp;&nbsp;
    17501769                     <ul class="ind">
    1751                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.2"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.n.5"><b>4.2.2</b></a></li>
     1770                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.2"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.n.5"><b>3.2.2</b></a></li>
    17521771                     </ul>
    17531772                  </li>
    17541773                  <li class="indline1">no-transform&nbsp;&nbsp;
    17551774                     <ul class="ind">
    1756                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.3"><b>4.2.1</b></a>, <a class="iref" href="#rfc.iref.n.6"><b>4.2.2</b></a></li>
     1775                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.n.3"><b>3.2.1</b></a>, <a class="iref" href="#rfc.iref.n.6"><b>3.2.2</b></a></li>
    17571776                     </ul>
    17581777                  </li>
     
    17621781                  <li class="indline1">only-if-cached&nbsp;&nbsp;
    17631782                     <ul class="ind">
    1764                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1"><b>4.2.1</b></a></li>
     1783                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1"><b>3.2.1</b></a></li>
    17651784                     </ul>
    17661785                  </li>
     
    17681787            </li>
    17691788            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    1770                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">2</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3.2</a>, <a class="iref" href="#rfc.xref.Part1.14">3.6</a>, <a class="iref" href="#rfc.xref.Part1.15">4.3</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.16">A.1</a><ul class="ind">
    1771                         <li class="indline1"><em>Section 1.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">2</a></li>
    1772                         <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li>
    1773                         <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li>
    1774                         <li class="indline1"><em>Section 3.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.15">4.3</a></li>
    1775                         <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.14">3.6</a></li>
    1776                         <li class="indline1"><em>Section 8.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">3.3.2</a></li>
    1777                         <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">2</a></li>
    1778                      </ul>
    1779                   </li>
    1780                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.5</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
    1781                         <li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.5</a></li>
    1782                      </ul>
    1783                   </li>
    1784                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">3.6</a>, <a class="iref" href="#Part3"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part3.2">A.1</a><ul class="ind">
    1785                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">3.6</a></li>
    1786                      </ul>
    1787                   </li>
    1788                   <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">3.4</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind">
    1789                         <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.3.1.1</a></li>
    1790                      </ul>
    1791                   </li>
    1792                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">3.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">3.7</a>, <a class="iref" href="#Part5"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">A.1</a><ul class="ind">
    1793                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">3.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">3.7</a></li>
    1794                      </ul>
    1795                   </li>
    1796                   <li class="indline1"><em>Part7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">3.2</a>, <a class="iref" href="#rfc.xref.Part7.2">4.2.2</a>, <a class="iref" href="#Part7"><b>9.1</b></a><ul class="ind">
    1797                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">3.2</a>, <a class="iref" href="#rfc.xref.Part7.2">4.2.2</a></li>
    1798                      </ul>
    1799                   </li>
    1800                   <li class="indline1">Pragma header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">3.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">4.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>4.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">6.1</a></li>
     1789                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part1.14">A.1</a><ul class="ind">
     1790                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a></li>
     1791                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li>
     1792                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li>
     1793                        <li class="indline1"><em>Section 3.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a></li>
     1794                        <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a></li>
     1795                        <li class="indline1"><em>Section 8.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">2.3.2</a></li>
     1796                        <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.4.2</a></li>
     1797                     </ul>
     1798                  </li>
     1799                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind">
     1800                        <li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.5</a></li>
     1801                     </ul>
     1802                  </li>
     1803                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.6</a>, <a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.2">A.1</a><ul class="ind">
     1804                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.6</a></li>
     1805                     </ul>
     1806                  </li>
     1807                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind">
     1808                        <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a></li>
     1809                     </ul>
     1810                  </li>
     1811                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">2.7</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">A.1</a><ul class="ind">
     1812                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.3">2.7</a></li>
     1813                     </ul>
     1814                  </li>
     1815                  <li class="indline1"><em>Part7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">2.2</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.2</a>, <a class="iref" href="#Part7"><b>8.1</b></a><ul class="ind">
     1816                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">2.2</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.2</a></li>
     1817                     </ul>
     1818                  </li>
     1819                  <li class="indline1">Pragma header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li>
    18011820                  <li class="indline1">private&nbsp;&nbsp;
    18021821                     <ul class="ind">
    1803                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2"><b>4.2.2</b></a></li>
     1822                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2"><b>3.2.2</b></a></li>
    18041823                     </ul>
    18051824                  </li>
    18061825                  <li class="indline1">proxy-revalidate&nbsp;&nbsp;
    18071826                     <ul class="ind">
    1808                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.3"><b>4.2.2</b></a></li>
     1827                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.3"><b>3.2.2</b></a></li>
    18091828                     </ul>
    18101829                  </li>
    18111830                  <li class="indline1">public&nbsp;&nbsp;
    18121831                     <ul class="ind">
    1813                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>4.2.2</b></a></li>
     1832                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>3.2.2</b></a></li>
    18141833                     </ul>
    18151834                  </li>
     
    18171836            </li>
    18181837            <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
    1819                   <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">3.3.2</a>, <a class="iref" href="#RFC1305"><b>9.2</b></a></li>
    1820                   <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">4.6</a>, <a class="iref" href="#RFC2047"><b>9.1</b></a></li>
    1821                   <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.3</a>, <a class="iref" href="#RFC2119"><b>9.1</b></a></li>
    1822                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li>
    1823                   <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">6.1</a>, <a class="iref" href="#RFC3864"><b>9.2</b></a></li>
     1838                  <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">2.3.2</a>, <a class="iref" href="#RFC1305"><b>8.2</b></a></li>
     1839                  <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">3.6</a>, <a class="iref" href="#RFC2047"><b>8.1</b></a></li>
     1840                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.3</a>, <a class="iref" href="#RFC2119"><b>8.1</b></a></li>
     1841                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#RFC2616"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li>
     1842                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">5.1</a>, <a class="iref" href="#RFC3864"><b>8.2</b></a></li>
     1843                  <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.4</a>, <a class="iref" href="#RFC5234"><b>8.1</b></a><ul class="ind">
     1844                        <li class="indline1"><em>Appendix B.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.4</a></li>
     1845                     </ul>
     1846                  </li>
    18241847               </ul>
    18251848            </li>
     
    18271850                  <li class="indline1">s-maxage&nbsp;&nbsp;
    18281851                     <ul class="ind">
    1829                         <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.2"><b>4.2.2</b></a></li>
     1852                        <li class="indline1">Cache Directive&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.2"><b>3.2.2</b></a></li>
    18301853                     </ul>
    18311854                  </li>
     
    18351858            <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind">
    18361859                  <li class="indline1">validator&nbsp;&nbsp;<a class="iref" href="#rfc.iref.v.1">1.2</a>, <a class="iref" href="#rfc.iref.v.2">1.2</a></li>
    1837                   <li class="indline1">Vary header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">3.6</a>, <a class="iref" href="#rfc.iref.v.3"><b>4.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">6.1</a></li>
     1860                  <li class="indline1">Vary header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">2.6</a>, <a class="iref" href="#rfc.iref.v.3"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.1</a></li>
    18381861               </ul>
    18391862            </li>
    18401863            <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind">
    1841                   <li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">3.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>4.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">6.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
     1864                  <li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
    18421865               </ul>
    18431866            </li>
  • draft-ietf-httpbis/latest-roy/p6-cache.xml

    r441 r442  
    1515  <!ENTITY ID-MONTH "December">
    1616  <!ENTITY ID-YEAR "2008">
    17   <!ENTITY notation-abnf               "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     17  <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1818  <!ENTITY basic-rules                 "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1919  <!ENTITY uri                         "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    326326          requirements for its protocols is said to be "conditionally compliant."</t>
    327327      </section>
    328     </section>
    329 
    330 
    331     <section anchor="notation" title="Notational Conventions and Generic Grammar">
    332       <x:anchor-alias value="DIGIT" />
    333       <x:anchor-alias value="DQUOTE" />
    334       <x:anchor-alias value="quoted-string" />
    335       <x:anchor-alias value="SP" />
    336       <x:anchor-alias value="token" />
    337       <t>This specification uses the ABNF syntax defined in &notation-abnf; and the core rules
    338         defined in &basic-rules;: <cref anchor="abnf.dep">ABNF syntax and basic rules will be
    339           adopted from RFC 5234, see <eref target="http://ietf.org/wg/httpbis/trac/ticket/36"
    340          />.</cref>
    341       </t>
    342       <figure>
    343         <artwork type="abnf2616">
    344   <x:ref>DIGIT</x:ref>         = &lt;DIGIT, defined in &basic-rules;&gt;
    345   <x:ref>DQUOTE</x:ref>        = &lt;DQUOTE, defined in &basic-rules;&gt;
    346   <x:ref>SP</x:ref>            = &lt;SP, defined in &basic-rules;&gt;
    347 </artwork>
    348       </figure>
    349       <figure>
    350         <artwork type="abnf2616">
     328
     329
     330<section title="Syntax Notation" anchor="notation">
     331  <x:anchor-alias value="ALPHA"/>
     332  <x:anchor-alias value="CR"/>
     333  <x:anchor-alias value="DIGIT"/>
     334  <x:anchor-alias value="DQUOTE"/>
     335  <x:anchor-alias value="LF"/>
     336  <x:anchor-alias value="OCTET"/>
     337  <x:anchor-alias value="SP"/>
     338  <x:anchor-alias value="VCHAR"/>
     339  <x:anchor-alias value="WSP"/>
     340<t>
     341  This specification uses the ABNF syntax defined in &notation;.
     342  The following core rules are included by
     343  reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
     344  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
     345  DIGIT (decimal 0-9), DQUOTE (double quote),
     346  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
     347  OCTET (any 8-bit sequence of data), SP (space),
     348  VCHAR (any visible USASCII character),
     349  and WSP (whitespace).
     350</t>
     351
     352<section title="Core Rules" anchor="core.rules">
     353  <x:anchor-alias value="quoted-string"/>
     354  <x:anchor-alias value="token"/>
     355  <x:anchor-alias value="OWS"/>
     356<t>
     357  The core rules below are defined in &basic-rules;:
     358</t>
     359<figure><artwork type="abnf2616">
    351360  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &basic-rules;&gt;
    352361  <x:ref>token</x:ref>         = &lt;token, defined in &basic-rules;&gt;
    353 </artwork>
    354       </figure>
    355       <t anchor="abnf.dependencies">
    356         <x:anchor-alias value="field-name" />
    357         <x:anchor-alias value="HTTP-date" />
    358         <x:anchor-alias value="port" />
    359         <x:anchor-alias value="pseudonym" />
    360         <x:anchor-alias value="uri-host" /> The ABNF rules below are defined in other parts:</t>
    361       <figure>
    362         <!--Part1-->
    363         <artwork type="abnf2616">
     362  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
     363</artwork></figure>
     364</section>
     365
     366<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
     367  <x:anchor-alias value="field-name"/>
     368  <x:anchor-alias value="HTTP-date"/>
     369  <x:anchor-alias value="port"/>
     370  <x:anchor-alias value="pseudonym"/>
     371  <x:anchor-alias value="uri-host"/>
     372<t>
     373  The ABNF rules below are defined in other parts:
     374</t>
     375<figure><!--Part1--><artwork type="abnf2616">
    364376  <x:ref>field-name</x:ref>    = &lt;field-name, defined in &message-headers;&gt;
    365377  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &full-date;&gt;
     
    367379  <x:ref>pseudonym</x:ref>     = &lt;pseudonym, defined in &header-via;&gt;
    368380  <x:ref>uri-host</x:ref>      = &lt;uri-host, defined in &uri;&gt;
    369 </artwork>
    370       </figure>
    371     </section>
     381</artwork></figure>
     382</section>
     383
     384</section>
     385</section>
    372386
    373387    <section anchor="caching.overview" title="Cache Operation">
     
    764778        <iref item="Age header" primary="true" x:for-anchor="" />
    765779        <iref item="Headers" primary="true" subitem="Age" x:for-anchor="" />
    766         <x:anchor-alias value="Age" />
    767         <x:anchor-alias value="age-value" />
    768         <t>The Age response-header field conveys the sender's estimate of the amount of time since
     780        <x:anchor-alias value="Age"/>
     781        <x:anchor-alias value="Age-v"/>
     782        <x:anchor-alias value="age-value"/>
     783        <t>      The response-header field "Age" conveys the sender's estimate of the amount of time since
    769784          the response (or its validation) was generated at the origin server. Age values are
    770785          calculated as specified in <xref target="age.calculations" />.</t>
    771         <figure>
    772           <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Age" /><iref item="Grammar" primary="true" subitem="age-value" />
    773   <x:ref>Age</x:ref> = "Age" ":" <x:ref>age-value</x:ref>
    774   <x:ref>age-value</x:ref> = <x:ref>delta-seconds</x:ref>
    775 </artwork>
    776         </figure>
     786<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/><iref primary="true" item="Grammar" subitem="Age-v"/>
     787  <x:ref>Age</x:ref>   = "Age" ":" <x:ref>OWS</x:ref> <x:ref>Age-v</x:ref>
     788  <x:ref>Age-v</x:ref> = <x:ref>delta-seconds</x:ref>
     789</artwork></figure>
    777790        <t anchor="rule.delta-seconds">
    778791          <x:anchor-alias value="delta-seconds" /> Age field-values are non-negative decimal
     
    795808        <iref item="Cache-Control header" primary="true" x:for-anchor="" />
    796809        <iref item="Headers" primary="true" subitem="Cache-Control" x:for-anchor="" />
    797         <x:anchor-alias value="Cache-Control" />
    798         <x:anchor-alias value="cache-directive" />
    799         <x:anchor-alias value="cache-extension" />
    800         <t>The Cache-Control general-header field is used to specify directives that &MUST; be
     810        <x:anchor-alias value="Cache-Control"/>
     811        <x:anchor-alias value="Cache-Control-v"/>
     812        <x:anchor-alias value="cache-directive"/>
     813        <x:anchor-alias value="cache-extension"/>
     814        <x:anchor-alias value="cache-request-directive"/>
     815        <x:anchor-alias value="cache-response-directive"/>
     816        <t>The general-header field "Cache-Control" is used to specify directives that &MUST; be
    801817          obeyed by all caches along the request/response chain. The directives specify behavior
    802818          intended to prevent caches from adversely interfering with the request or response. Cache
     
    811827          applicable to all recipients along the request/response chain. It is not possible to
    812828          target a directive to a specific cache.</t>
    813         <figure>
    814           <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Cache-Control" /><iref item="Grammar" primary="true" subitem="cache-directive" /><iref item="Grammar" primary="true" subitem="cache-extension" />
    815   <x:ref>Cache-Control</x:ref>   = "Cache-Control" ":" 1#<x:ref>cache-directive</x:ref>
     829<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="Cache-Control-v"/><iref primary="true" item="Grammar" subitem="cache-extension"/>
     830  <x:ref>Cache-Control</x:ref>   = "Cache-Control" ":" <x:ref>OWS</x:ref> <x:ref>Cache-Control-v</x:ref>
     831  <x:ref>Cache-Control-v</x:ref> = 1#<x:ref>cache-directive</x:ref>
    816832
    817833  <x:ref>cache-directive</x:ref> = <x:ref>cache-request-directive</x:ref>
     
    819835
    820836  <x:ref>cache-extension</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ]
    821 </artwork>
    822         </figure>
    823 
     837</artwork></figure>
    824838
    825839        <section anchor="cache-request-directive" title="Request Cache-Control Directives">
     
    10781092        <iref item="Expires header" primary="true" x:for-anchor="" />
    10791093        <iref item="Headers" primary="true" subitem="Expires" x:for-anchor="" />
    1080         <x:anchor-alias value="Expires" />
     1094        <x:anchor-alias value="Expires"/>
     1095        <x:anchor-alias value="Expires-v"/>
    10811096        <t>The Expires entity-header field gives the date/time after which the response is
    10821097          considered stale. See <xref target="expiration.model" /> for further discussion of the
     
    10861101        <t>The field-value is an absolute date and time as defined by HTTP-date in &full-date;;
    10871102          it &MUST; be sent in rfc1123-date format.</t>
    1088         <figure>
    1089           <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Expires" />
    1090   <x:ref>Expires</x:ref> = "Expires" ":" <x:ref>HTTP-date</x:ref>
    1091 </artwork>
    1092         </figure>
     1103<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/><iref primary="true" item="Grammar" subitem="Expires-v"/>
     1104  <x:ref>Expires</x:ref>   = "Expires" ":" <x:ref>OWS</x:ref> <x:ref>Expires-v</x:ref>
     1105  <x:ref>Expires-v</x:ref> = <x:ref>HTTP-date</x:ref>
     1106</artwork></figure>
    10931107        <t>For example</t>
    10941108        <figure>
     
    11131127        <iref item="Pragma header" primary="true" x:for-anchor="" />
    11141128        <iref item="Headers" primary="true" subitem="Pragma" x:for-anchor="" />
    1115         <x:anchor-alias value="extension-pragma" />
    1116         <x:anchor-alias value="Pragma" />
    1117         <x:anchor-alias value="pragma-directive" />
    1118         <t>The Pragma general-header field is used to include implementation-specific directives
     1129        <x:anchor-alias value="extension-pragma"/>
     1130        <x:anchor-alias value="Pragma"/>
     1131        <x:anchor-alias value="Pragma-v"/>
     1132        <x:anchor-alias value="pragma-directive"/>
     1133        <t>The general-header field "Pragma" is used to include implementation-specific directives
    11191134          that might apply to any recipient along the request/response chain. All pragma directives
    11201135          specify optional behavior from the viewpoint of the protocol; however, some systems
    11211136          &MAY; require that behavior be consistent with the directives.</t>
    1122         <figure>
    1123           <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Pragma" /><iref item="Grammar" primary="true" subitem="pragma-directive" /><iref item="Grammar" primary="true" subitem="extension-pragma" />
    1124   <x:ref>Pragma</x:ref>            = "Pragma" ":" 1#<x:ref>pragma-directive</x:ref>
     1137<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Pragma"/><iref primary="true" item="Grammar" subitem="Pragma-v"/><iref primary="true" item="Grammar" subitem="pragma-directive"/><iref primary="true" item="Grammar" subitem="extension-pragma"/>
     1138  <x:ref>Pragma</x:ref>            = "Pragma" ":" <x:ref>OWS</x:ref> <x:ref>Pragma-v</x:ref>
     1139  <x:ref>Pragma-v</x:ref>          = 1#<x:ref>pragma-directive</x:ref>
    11251140  <x:ref>pragma-directive</x:ref>  = "no-cache" / <x:ref>extension-pragma</x:ref>
    11261141  <x:ref>extension-pragma</x:ref>  = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ]
    1127 </artwork>
    1128         </figure>
     1142</artwork></figure>
    11291143        <t>When the no-cache directive is present in a request message, an application &SHOULD;
    11301144          forward the request toward the origin server even if it has a cached copy of what is being
     
    11481162        <iref item="Vary header" primary="true" x:for-anchor="" />
    11491163        <iref item="Headers" primary="true" subitem="Vary" x:for-anchor="" />
    1150         <x:anchor-alias value="Vary" />
    1151         <t>The Vary response-header field's value indicates the set of request-header fields that
     1164        <x:anchor-alias value="Vary"/>
     1165        <x:anchor-alias value="Vary-v"/>
     1166        <t>The "Vary" response-header field's value indicates the set of request-header fields that
    11521167          fully determines, while the response is fresh, whether a cache is permitted to use the
    11531168          response to reply to a subsequent request without validation. For uncacheable or stale
     
    11571172          appropriate representation. See <xref target="caching.negotiated.responses" /> for use of
    11581173          the Vary header field by caches.</t>
    1159         <figure>
    1160           <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Vary" />
    1161   <x:ref>Vary</x:ref>  = "Vary" ":" ( "*" / 1#<x:ref>field-name</x:ref> )
    1162 </artwork>
    1163         </figure>
     1174<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Vary"/><iref primary="true" item="Grammar" subitem="Vary-v"/>
     1175  <x:ref>Vary</x:ref>   = "Vary" ":" <x:ref>OWS</x:ref> <x:ref>Vary-v</x:ref>
     1176  <x:ref>Vary-v</x:ref> = "*" / 1#<x:ref>field-name</x:ref>
     1177</artwork></figure>
    11641178        <t>The set of header fields named by the Vary field value is known as the "selecting"
    11651179          request-headers.</t>
     
    11821196        <iref item="Warning header" primary="true" x:for-anchor="" />
    11831197        <iref item="Headers" primary="true" subitem="Warning" x:for-anchor="" />
    1184         <x:anchor-alias value="Warning" />
    1185         <x:anchor-alias value="warning-value" />
    1186         <x:anchor-alias value="warn-agent" />
    1187         <x:anchor-alias value="warn-code" />
    1188         <x:anchor-alias value="warn-date" />
    1189         <x:anchor-alias value="warn-text" />
    1190         <t>The Warning general-header field is used to carry additional information about the status
     1198        <x:anchor-alias value="Warning"/>
     1199        <x:anchor-alias value="Warning-v"/>
     1200        <x:anchor-alias value="warning-value"/>
     1201        <x:anchor-alias value="warn-agent"/>
     1202        <x:anchor-alias value="warn-code"/>
     1203        <x:anchor-alias value="warn-date"/>
     1204        <x:anchor-alias value="warn-text"/>
     1205        <t>The general-header field "Warning" is used to carry additional information about the status
    11911206          or transformation of a message which might not be reflected in the message. This
    11921207          information is typically used to warn about possible incorrectness introduced by caching
     
    11981213          specific to caches and can only be applied to response messages.</t>
    11991214
    1200         <figure>
    1201           <artwork type="abnf2616"><iref item="Grammar" primary="true" subitem="Warning" /><iref item="Grammar" primary="true" subitem="warning-value" /><iref item="Grammar" primary="true" subitem="warn-code" /><iref item="Grammar" primary="true" subitem="warn-agent" /><iref item="Grammar" primary="true" subitem="warn-text" /><iref item="Grammar" primary="true" subitem="warn-date" />
    1202   <x:ref>Warning</x:ref>    = "Warning" ":" 1#<x:ref>warning-value</x:ref>
     1215<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Warning"/><iref primary="true" item="Grammar" subitem="Warning-v"/><iref primary="true" item="Grammar" subitem="warning-value"/><iref primary="true" item="Grammar" subitem="warn-code"/><iref primary="true" item="Grammar" subitem="warn-agent"/><iref primary="true" item="Grammar" subitem="warn-text"/><iref primary="true" item="Grammar" subitem="warn-date"/>
     1216  <x:ref>Warning</x:ref>    = "Warning" ":" <x:ref>OWS</x:ref> <x:ref>Warning-v</x:ref>
     1217  <x:ref>Warning-v</x:ref>  = 1#<x:ref>warning-value</x:ref>
    12031218 
    12041219  <x:ref>warning-value</x:ref> = <x:ref>warn-code</x:ref> <x:ref>SP</x:ref> <x:ref>warn-agent</x:ref> <x:ref>SP</x:ref> <x:ref>warn-text</x:ref>
     
    12111226  <x:ref>warn-text</x:ref>  = <x:ref>quoted-string</x:ref>
    12121227  <x:ref>warn-date</x:ref>  = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref>
    1213 </artwork>
    1214         </figure>
     1228</artwork></figure>
    12151229
    12161230        <t>Multiple warnings &MAY; be attached to a response (either by the origin server or by
     
    17121726      </reference>
    17131727
     1728      <reference anchor="RFC5234">
     1729        <front>
     1730          <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
     1731          <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
     1732            <organization>Brandenburg InternetWorking</organization>
     1733            <address>
     1734            <postal>
     1735            <street>675 Spruce Dr.</street>
     1736            <city>Sunnyvale</city>
     1737            <region>CA</region>
     1738            <code>94086</code>
     1739            <country>US</country></postal>
     1740            <phone>+1.408.246.8253</phone>
     1741            <email>dcrocker@bbiw.net</email></address> 
     1742          </author>
     1743          <author initials="P." surname="Overell" fullname="Paul Overell">
     1744            <organization>THUS plc.</organization>
     1745            <address>
     1746            <postal>
     1747            <street>1/2 Berkeley Square</street>
     1748            <street>99 Berkely Street</street>
     1749            <city>Glasgow</city>
     1750            <code>G3 7HR</code>
     1751            <country>UK</country></postal>
     1752            <email>paul.overell@thus.net</email></address>
     1753          </author>
     1754          <date month="January" year="2008"/>
     1755        </front>
     1756        <seriesInfo name="STD" value="68"/>
     1757        <seriesInfo name="RFC" value="5234"/>
     1758      </reference>
     1759     
    17141760    </references>
    17151761
Note: See TracChangeset for help on using the changeset viewer.