Changeset 2372


Ignore:
Timestamp:
07/09/13 23:32:58 (9 years ago)
Author:
fielding@…
Message:

move all of the cache requirements added to p4 to a new section in p6; move related sections into the same outline and simplify section headers

Location:
draft-ietf-httpbis/latest
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2369 r2372  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 8, 2014";
     448       content: "Expires March 11, 2014";
    449449  }
    450450  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-09-07">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    519519            <tr>
    520520               <td class="left">Intended status: Standards Track</td>
    521                <td class="right">September 4, 2013</td>
     521               <td class="right">September 7, 2013</td>
    522522            </tr>
    523523            <tr>
    524                <td class="left">Expires: March 8, 2014</td>
     524               <td class="left">Expires: March 11, 2014</td>
    525525               <td class="right"></td>
    526526            </tr>
    … …  
    550550         in progress”.
    551551      </p>
    552       <p>This Internet-Draft will expire on March 8, 2014.</p>
     552      <p>This Internet-Draft will expire on March 11, 2014.</p>
    553553      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    554554      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    14161416         existing implementations to reject the request.
    14171417      </p>
    1418       <p id="rfc.section.4.3.1.p.5">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1418      <p id="rfc.section.4.3.1.p.5">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    14191419      </p>
    14201420      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
    … …  
    14271427         existing implementations to reject the request.
    14281428      </p>
    1429       <p id="rfc.section.4.3.2.p.3">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     1429      <p id="rfc.section.4.3.2.p.3">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached responses to GET; see <a href="p6-cache.html#head.effects" title="Freshening Responses via HEAD">Section 4.3.5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    14301430      </p>
    14311431      <div id="rfc.iref.p.2"></div>
    … …  
    14471447         origin server <em class="bcp14">SHOULD</em> send a <a href="#status.201" class="smpl">201 (Created)</a> response containing a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (<a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.2</a>) and a representation that describes the status of the request while referring to the new resource(s).
    14481448      </p>
    1449       <p id="rfc.section.4.3.3.p.4">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache
     1449      <p id="rfc.section.4.3.3.p.4">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache
    14501450         the result of a POST in a way that can be reused by a later GET, the origin server <em class="bcp14">MAY</em> send a <a href="#status.200" class="smpl">200 (OK)</a> response containing the result and a <a href="#header.content-location" class="smpl">Content-Location</a> header field that has the same value as the POST's effective request URI (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4.2</a>).
    14511451      </p>
    … …  
    15211521      </p>
    15221522      <p id="rfc.section.4.3.4.p.12">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses
    1523          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1523         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation" title="Invalidation">Section 4.4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    15241524      </p>
    15251525      <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
    … …  
    15471547      </p>
    15481548      <p id="rfc.section.4.3.5.p.6">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
    1549          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1549         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation" title="Invalidation">Section 4.4</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    15501550      </p>
    15511551      <div id="rfc.iref.c.9"></div>
    … …  
    16461646               <tr>
    16471647                  <td class="left">Cache-Control</td>
    1648                   <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
     1648                  <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    16491649               </tr>
    16501650               <tr>
    … …  
    16621662               <tr>
    16631663                  <td class="left">Pragma</td>
    1664                   <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 7.4</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
     1664                  <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 5.4</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    16651665               </tr>
    16661666               <tr>
    … …  
    24782478         200 response header block.
    24792479      </p>
    2480       <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2480      <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    24812481      </p>
    24822482      <div id="rfc.iref.74"></div>
    … …  
    25052505         applicable along the same request path (through the same proxies).
    25062506      </p>
    2507       <p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), which has the advantage of being applicable to responses with any status code.
    2508       </p>
    2509       <p id="rfc.section.6.3.4.p.3">A 203 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2507      <p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), which has the advantage of being applicable to responses with any status code.
     2508      </p>
     2509      <p id="rfc.section.6.3.4.p.3">A 203 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    25102510      </p>
    25112511      <div id="rfc.iref.74"></div>
    … …  
    25272527      </p>
    25282528      <p id="rfc.section.6.3.5.p.5">A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.</p>
    2529       <p id="rfc.section.6.3.5.p.6">A 204 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2529      <p id="rfc.section.6.3.5.p.6">A 204 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    25302530      </p>
    25312531      <div id="rfc.iref.74"></div>
    … …  
    25922592         for such automatic selection.
    25932593      </p>
    2594       <p id="rfc.section.6.4.1.p.4">A 300 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2594      <p id="rfc.section.6.4.1.p.4">A 300 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    25952595      </p>
    25962596      <div class="note" id="rfc.section.6.4.1.p.5">
    … …  
    26142614         </p>
    26152615      </div>
    2616       <p id="rfc.section.6.4.2.p.4">A 301 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2616      <p id="rfc.section.6.4.2.p.4">A 301 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    26172617      </p>
    26182618      <div id="rfc.iref.75"></div>
    … …  
    26982698         is likely to be permanent.
    26992699      </p>
    2700       <p id="rfc.section.6.5.4.p.2">A 404 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2700      <p id="rfc.section.6.5.4.p.2">A 404 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    27012701      </p>
    27022702      <div id="rfc.iref.76"></div>
    … …  
    27042704      <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.
    27052705      </p>
    2706       <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2706      <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    27072707      </p>
    27082708      <div id="rfc.iref.76"></div>
    … …  
    27412741         any length of time — that is left to the discretion of the server owner.
    27422742      </p>
    2743       <p id="rfc.section.6.5.9.p.3">A 410 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2743      <p id="rfc.section.6.5.9.p.3">A 410 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    27442744      </p>
    27452745      <div id="rfc.iref.76"></div>
    … …  
    27622762         attempting to exploit potential security holes.
    27632763      </p>
    2764       <p id="rfc.section.6.5.12.p.2">A 414 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2764      <p id="rfc.section.6.5.12.p.2">A 414 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    27652765      </p>
    27662766      <div id="rfc.iref.76"></div>
    … …  
    28022802         response when the server does not recognize the request method and is not capable of supporting it for any resource.
    28032803      </p>
    2804       <p id="rfc.section.6.6.2.p.2">A 501 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2804      <p id="rfc.section.6.6.2.p.2">A 501 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    28052805      </p>
    28062806      <div id="rfc.iref.77"></div>
    … …  
    28532853               <tr>
    28542854                  <td class="left">Age</td>
    2855                   <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
     2855                  <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 5.1</a> of <a href="#Part6" id="rfc.xref.Part6.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    28562856               </tr>
    28572857               <tr>
    28582858                  <td class="left">Cache-Control</td>
    2859                   <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
     2859                  <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    28602860               </tr>
    28612861               <tr>
    28622862                  <td class="left">Expires</td>
    2863                   <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
     2863                  <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 5.3</a> of <a href="#Part6" id="rfc.xref.Part6.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    28642864               </tr>
    28652865               <tr>
    … …  
    28812881               <tr>
    28822882                  <td class="left">Warning</td>
    2883                   <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
     2883                  <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    28842884               </tr>
    28852885            </tbody>
    … …  
    30763076         <li>
    30773077            <p>To inform cache recipients that they <em class="bcp14">MUST NOT</em> use this response to satisfy a later request unless the later request has the same values for the listed fields as the original
    3078                request (<a href="p6-cache.html#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry.
     3078               request (<a href="p6-cache.html#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a> of <a href="#Part6" id="rfc.xref.Part6.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry.
    30793079            </p>
    30803080         </li>
    … …  
    30883088         other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately
    30893089         configured to prevent cache transparency. For example, there is no need to send the Authorization field name in Vary because
    3090          reuse across users is constrained by the field definition (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>). Likewise, an origin server might use Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.
     3090         reuse across users is constrained by the field definition (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>). Likewise, an origin server might use Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.
    30913091      </p>
    30923092      <div id="rfc.iref.s.8"></div>
    … …  
    47934793                  </li>
    47944794                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.2.3</a>, <a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.9">5.1</a>, <a href="#rfc.xref.Part6.10">6.1</a>, <a href="#rfc.xref.Part6.11">6.3.1</a>, <a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.3.5</a>, <a href="#rfc.xref.Part6.15">6.4.1</a>, <a href="#rfc.xref.Part6.16">6.4.2</a>, <a href="#rfc.xref.Part6.17">6.5.4</a>, <a href="#rfc.xref.Part6.18">6.5.5</a>, <a href="#rfc.xref.Part6.19">6.5.9</a>, <a href="#rfc.xref.Part6.20">6.5.12</a>, <a href="#rfc.xref.Part6.21">6.6.2</a>, <a href="#rfc.xref.Part6.22">7.1</a>, <a href="#rfc.xref.Part6.23">7.1</a>, <a href="#rfc.xref.Part6.24">7.1</a>, <a href="#rfc.xref.Part6.25">7.1</a>, <a href="#rfc.xref.Part6.26">7.1.4</a>, <a href="#rfc.xref.Part6.27">7.1.4</a>, <a href="#rfc.xref.Part6.28">8.2.2</a>, <a href="#Part6"><b>11.1</b></a><ul>
    4795                         <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">4.3.3</a></li>
    4796                         <li><em>Section 4.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">6.3.1</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.3.5</a>, <a href="#rfc.xref.Part6.15">6.4.1</a>, <a href="#rfc.xref.Part6.16">6.4.2</a>, <a href="#rfc.xref.Part6.17">6.5.4</a>, <a href="#rfc.xref.Part6.18">6.5.5</a>, <a href="#rfc.xref.Part6.19">6.5.9</a>, <a href="#rfc.xref.Part6.20">6.5.12</a>, <a href="#rfc.xref.Part6.21">6.6.2</a></li>
    4797                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.26">7.1.4</a></li>
    4798                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">4.3.2</a></li>
    4799                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li>
    4800                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.22">7.1</a></li>
    4801                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.23">7.1</a>, <a href="#rfc.xref.Part6.27">7.1.4</a></li>
    4802                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.24">7.1</a></li>
    4803                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">5.1</a></li>
    4804                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.25">7.1</a></li>
     4795                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.26">7.1.4</a></li>
     4796                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">4.3.3</a></li>
     4797                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">6.3.1</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.3.5</a>, <a href="#rfc.xref.Part6.15">6.4.1</a>, <a href="#rfc.xref.Part6.16">6.4.2</a>, <a href="#rfc.xref.Part6.17">6.5.4</a>, <a href="#rfc.xref.Part6.18">6.5.5</a>, <a href="#rfc.xref.Part6.19">6.5.9</a>, <a href="#rfc.xref.Part6.20">6.5.12</a>, <a href="#rfc.xref.Part6.21">6.6.2</a></li>
     4798                        <li><em>Section 4.3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">4.3.2</a></li>
     4799                        <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li>
     4800                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.22">7.1</a></li>
     4801                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.23">7.1</a>, <a href="#rfc.xref.Part6.27">7.1.4</a></li>
     4802                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.24">7.1</a></li>
     4803                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">5.1</a></li>
     4804                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.25">7.1</a></li>
    48054805                     </ul>
    48064806                  </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2369 r2372  
    8989  <!ENTITY p6-heuristic               "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    9090  <!ENTITY p6-explicit                "<xref target='Part6' x:rel='#calculating.freshness.lifetime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    91   <!ENTITY p6-invalid                 "<xref target='Part6' x:rel='#invalidation.after.updates.or.deletions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     91  <!ENTITY p6-invalid                 "<xref target='Part6' x:rel='#invalidation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    9292  <!ENTITY p6-head                    "<xref target='Part6' x:rel='#head.effects' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    9393  <!ENTITY qvalue                     "<xref target='quality.values'/>">

  • draft-ietf-httpbis/latest/p4-conditional.html

    r2369 r2372  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 8, 2014";
     448       content: "Expires March 11, 2014";
    449449  }
    450450  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-09-07">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
    … …  
    515515            </tr>
    516516            <tr>
    517                <td class="left">Expires: March 8, 2014</td>
    518                <td class="right">September 4, 2013</td>
     517               <td class="left">Expires: March 11, 2014</td>
     518               <td class="right">September 7, 2013</td>
    519519            </tr>
    520520         </tbody>
    … …  
    543543         in progress”.
    544544      </p>
    545       <p>This Internet-Draft will expire on March 8, 2014.</p>
     545      <p>This Internet-Draft will expire on March 11, 2014.</p>
    546546      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    547547      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    933933      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#evaluation" title="Evaluation">Section&nbsp;5</a> defines when the preconditions are applied. <a href="#precedence" title="Precedence">Section&nbsp;6</a> defines the order of evaluation when more than one precondition is present.
    934934      </p>
     935      <p id="rfc.section.3.p.2">Requirements on a cache when handling a received conditional request are defined in <a href="p6-cache.html#validation.received" title="Handling a Received Validation Request">Section 4.3.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     936      </p>
    935937      <div id="rfc.iref.i.1"></div>
    936938      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    … …  
    957959         user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior
    958960         change made by the same user agent.
    959       </p>
    960       <p id="rfc.section.3.1.p.8">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">MUST</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">MUST</em> generate a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response if the field-value is "*" and no suitable response is stored, or if the field-value is a list of entity-tags and
    961          none of them match the entity-tag of a suitable stored response. Otherwise, the cache <em class="bcp14">MUST</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most recent of its matching stored responses to satisfy the request.
    962961      </p>
    963962      <div id="rfc.iref.i.2"></div>
    … …  
    989988      <p id="rfc.section.3.2.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD; or, b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods.
    990989      </p>
    991       <p id="rfc.section.3.2.p.9">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">SHOULD</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the field-value is "*" and a suitable response is stored, or the field-value is a list of entity-tags and at least one
    992          of them match the entity-tag of a suitable stored response, the cache <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response using the most suitable of those matching responses as the selected representation. Otherwise, if the cache has one
    993          or more suitable stored responses that do not match the condition, the cache <em class="bcp14">SHOULD</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most suitable of those stored responses to satisfy the request. Finally, if the cache has no suitable
    994          stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server; if the received condition contains a list of entity-tags and the
    995          cache has its own set of stored responses for that primary cache key, the cache <em class="bcp14">SHOULD</em> take the union of the received set with the set of entity-tags for its own stored set of responses (fresh or stale) and generate
    996          an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field containing that union when it forwards the request toward the origin server.
    997       </p>
    998990      <div id="rfc.iref.i.3"></div>
    999991      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    … …  
    10281020         selected representation's <a href="#header.last-modified" class="smpl">Last-Modified</a> field will not be able to help the user agent limit its data transfers to only those changed during the specified window.
    10291021      </p>
    1030       <p id="rfc.section.3.3.p.11">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">SHOULD</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server if it does not have any suitable stored responses. The cache <em class="bcp14">SHOULD</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response, reusing the most recent of its stored responses to satisfy the request, if one of the following is true: 1) a stored
    1031          response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.
    1032          Otherwise, the cache <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response using the most recent of the stored responses as the selected representation.
    1033       </p>
    10341022      <div id="rfc.iref.i.4"></div>
    10351023      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    … …  
    10581046         user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior
    10591047         change made by the same user agent.
    1060       </p>
    1061       <p id="rfc.section.3.4.p.11">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">MUST</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">MUST</em> forward the conditional request toward the origin server if it does not have any suitable stored responses. The cache <em class="bcp14">MUST</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most recent of its suitable stored responses to satisfy the request if that stored response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> date that is equal to or earlier than the date given in If-Unmodified-Since. Otherwise, the cache <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
    10621048      </p>
    10631049      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    … …  
    10791065         cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field).
    10801066      </p>
    1081       <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
     1067      <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3.4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional
    10821068         GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.
    10831069      </p>
    … …  
    15291515                     </ul>
    15301516                  </li>
    1531                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.2</a>, <a href="#rfc.xref.Part6.6">3.3</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">4.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    1532                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.2</a>, <a href="#rfc.xref.Part6.6">3.3</a>, <a href="#rfc.xref.Part6.7">3.4</a></li>
    1533                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">4.1</a></li>
     1517                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3</a>, <a href="#rfc.xref.Part6.5">4.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     1518                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3</a></li>
     1519                        <li><em>Section 4.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">4.1</a></li>
    15341520                     </ul>
    15351521                  </li>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2369 r2372  
    3030  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3131  <!ENTITY cache-key                  "<xref target='Part6' x:rel='#constructing.responses.from.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     32  <!ENTITY cache-validation-received  "<xref target='Part6' x:rel='#validation.received' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3233  <!ENTITY freshening-responses       "<xref target='Part6' x:rel='#freshening.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3334  <!ENTITY header-accept-encoding     "<xref target='Part2' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    658659   one precondition is present.
    659660</t>
     661<t>
     662   Requirements on a cache when handling a received conditional request are
     663   defined in &cache-validation-received;.
     664</t>
    660665
    661666<section title="If-Match" anchor="header.if-match">
    … …  
    714719   of an immediately prior change made by the same user agent.
    715720</t>
    716 <t>
    717    If the request semantics can be satisfied with a cached response, a
    718    recipient cache &MUST; evaluate the condition as part of its selection
    719    process for determining a suitable response for that primary cache key
    720    (see &cache-key;).
    721    The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref>
    722    response if the field-value is "*" and no suitable response is stored, or
    723    if the field-value is a list of entity-tags and none of them match the
    724    entity-tag of a suitable stored response.
    725    Otherwise, the cache &MUST; generate a successful <x:ref>2xx</x:ref>
    726    response that reuses the most recent of its matching stored responses to
    727    satisfy the request.
    728 </t>
    729721</section>
    730722
    … …  
    789781   b) the <x:ref>412 (Precondition Failed)</x:ref> status code for all other
    790782   request methods.
    791 </t>
    792 <t>
    793    If the request semantics can be satisfied with a cached response, a
    794    recipient cache &SHOULD; evaluate the condition as part of its selection
    795    process for determining a suitable response for that primary cache key
    796    (see &cache-key;). If the field-value is "*" and a suitable response is
    797    stored, or the field-value is a list of entity-tags and at least one of
    798    them match the entity-tag of a suitable stored response, the cache &SHOULD;
    799    generate a <x:ref>304 (Not Modified)</x:ref> response using the most
    800    suitable of those matching responses as the selected representation.
    801    Otherwise, if the cache has one or more suitable stored responses that
    802    do not match the condition, the cache &SHOULD; generate a successful
    803    <x:ref>2xx</x:ref> response that reuses the most suitable of those stored
    804    responses to satisfy the request. Finally, if the cache has no suitable
    805    stored responses, the cache &SHOULD; forward the conditional request toward
    806    the origin server; if the received condition contains a list of entity-tags
    807    and the cache has its own set of stored responses for that primary cache
    808    key, the cache &SHOULD; take the union of the received set with the set of
    809    entity-tags for its own stored set of responses (fresh or stale) and
    810    generate an <x:ref>If-None-Match</x:ref> header field containing that union
    811    when it forwards the request toward the origin server.
    812783</t>
    813784</section>
    … …  
    883854   field will not be able to help the user agent limit its data transfers to
    884855   only those changed during the specified window.
    885 </t>
    886 <t>
    887    If the request semantics can be satisfied with a cached response, a
    888    recipient cache &SHOULD; evaluate the condition as part of its selection
    889    process for determining a suitable response for that primary cache key
    890    (see &cache-key;).
    891    The cache &SHOULD; forward the conditional request toward the origin server
    892    if it does not have any suitable stored responses.
    893    The cache &SHOULD; generate a successful
    894    <x:ref>2xx</x:ref> response, reusing the most recent of its stored
    895    responses to satisfy the request, if one of the following is true:
    896    1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that
    897    is more recent than the conditional timestamp;
    898    2) no <x:ref>Last-Modified</x:ref> field is present, but a stored
    899    response has a <x:ref>Date</x:ref> field-value that is more recent than the
    900    conditional timestamp; or,
    901    3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present,
    902    but the cache recorded a stored response as having been received at a
    903    time more recent than the conditional timestamp.
    904    Otherwise, the cache &SHOULD; generate a <x:ref>304 (Not Modified)</x:ref>
    905    response using the most recent of the stored responses as the selected
    906    representation.
    907856</t>
    908857</section>
    … …  
    973922   of an immediately prior change made by the same user agent.
    974923</t>
    975 <t>
    976    If the request semantics can be satisfied with a cached response, a
    977    recipient cache &MUST; evaluate the condition as part of its selection
    978    process for determining a suitable response for that primary cache key
    979    (see &cache-key;).
    980    The cache &MUST; forward the conditional request toward the origin server
    981    if it does not have any suitable stored responses.
    982    The cache &MUST; generate a successful <x:ref>2xx</x:ref> response that
    983    reuses the most recent of its suitable stored responses to satisfy the
    984    request if that stored response has a <x:ref>Last-Modified</x:ref> date
    985    that is equal to or earlier than the date given in If-Unmodified-Since.
    986    Otherwise, the cache &MUST; respond with a
    987    <x:ref>412 (Precondition Failed)</x:ref> status code.
    988 </t>
    989924</section>
    990925
    … …  
    999934</t>
    1000935</section>
    1001 
    1002936</section>
    1003937

  • draft-ietf-httpbis/latest/p6-cache.html

    r2371 r2372  
    475475      <link rel="Chapter" title="3 Storing Responses in Caches" href="#rfc.section.3">
    476476      <link rel="Chapter" title="4 Constructing Responses from Caches" href="#rfc.section.4">
    477       <link rel="Chapter" title="5 Updating Caches with HEAD Responses" href="#rfc.section.5">
    478       <link rel="Chapter" title="6 Request Methods that Invalidate" href="#rfc.section.6">
    479       <link rel="Chapter" title="7 Header Field Definitions" href="#rfc.section.7">
    480       <link rel="Chapter" title="8 History Lists" href="#rfc.section.8">
    481       <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9">
    482       <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10">
    483       <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11">
    484       <link rel="Chapter" href="#rfc.section.12" title="12 References">
     477      <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5">
     478      <link rel="Chapter" title="6 History Lists" href="#rfc.section.6">
     479      <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7">
     480      <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8">
     481      <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9">
     482      <link rel="Chapter" href="#rfc.section.10" title="10 References">
    485483      <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A">
    486484      <link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B">
    … …  
    599597               </li>
    600598               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul>
    601                      <li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li>
     599                     <li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#validation.sent">Sending a Validation Request</a></li>
     600                     <li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.received">Handling a Received Validation Request</a></li>
     601                     <li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.response">Handling a Validation Response</a></li>
     602                     <li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li>
     603                     <li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#head.effects">Freshening Responses via HEAD</a></li>
     604                  </ul>
     605               </li>
     606               <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#invalidation">Invalidation</a></li>
     607            </ul>
     608         </li>
     609         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
     610               <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li>
     611               <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul>
     612                     <li><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a><ul>
     613                           <li><a href="#rfc.section.5.2.1.1">5.2.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.max-age">max-age</a></li>
     614                           <li><a href="#rfc.section.5.2.1.2">5.2.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.max-stale">max-stale</a></li>
     615                           <li><a href="#rfc.section.5.2.1.3">5.2.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.min-fresh">min-fresh</a></li>
     616                           <li><a href="#rfc.section.5.2.1.4">5.2.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.no-cache">no-cache</a></li>
     617                           <li><a href="#rfc.section.5.2.1.5">5.2.1.5</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.no-store">no-store</a></li>
     618                           <li><a href="#rfc.section.5.2.1.6">5.2.1.6</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.no-transform">no-transform</a></li>
     619                           <li><a href="#rfc.section.5.2.1.7">5.2.1.7</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.only-if-cached">only-if-cached</a></li>
     620                        </ul>
     621                     </li>
     622                     <li><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a><ul>
     623                           <li><a href="#rfc.section.5.2.2.1">5.2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.must-revalidate">must-revalidate</a></li>
     624                           <li><a href="#rfc.section.5.2.2.2">5.2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.no-cache">no-cache</a></li>
     625                           <li><a href="#rfc.section.5.2.2.3">5.2.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.no-store">no-store</a></li>
     626                           <li><a href="#rfc.section.5.2.2.4">5.2.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.no-transform">no-transform</a></li>
     627                           <li><a href="#rfc.section.5.2.2.5">5.2.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.public">public</a></li>
     628                           <li><a href="#rfc.section.5.2.2.6">5.2.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.private">private</a></li>
     629                           <li><a href="#rfc.section.5.2.2.7">5.2.2.7</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></li>
     630                           <li><a href="#rfc.section.5.2.2.8">5.2.2.8</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.max-age">max-age</a></li>
     631                           <li><a href="#rfc.section.5.2.2.9">5.2.2.9</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.s-maxage">s-maxage</a></li>
     632                        </ul>
     633                     </li>
     634                     <li><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li>
     635                  </ul>
     636               </li>
     637               <li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li>
     638               <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li>
     639               <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a><ul>
     640                     <li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">110 Response is Stale</a></li>
     641                     <li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">111 Revalidation Failed</a></li>
     642                     <li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">112 Disconnected Operation</a></li>
     643                     <li><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">113 Heuristic Expiration</a></li>
     644                     <li><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">199 Miscellaneous Warning</a></li>
     645                     <li><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">214 Transformation Applied</a></li>
     646                     <li><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">299 Miscellaneous Persistent Warning</a></li>
     647                     <li><a href="#rfc.section.5.5.8">5.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.extensions">Warn Code Extensions</a></li>
    602648                  </ul>
    603649               </li>
    604650            </ul>
    605651         </li>
    606          <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#head.effects">Updating Caches with HEAD Responses</a></li>
    607          <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li>
    608          <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    609                <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li>
    610                <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul>
    611                      <li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a><ul>
    612                            <li><a href="#rfc.section.7.2.1.1">7.2.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.max-age">max-age</a></li>
    613                            <li><a href="#rfc.section.7.2.1.2">7.2.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.max-stale">max-stale</a></li>
    614                            <li><a href="#rfc.section.7.2.1.3">7.2.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.min-fresh">min-fresh</a></li>
    615                            <li><a href="#rfc.section.7.2.1.4">7.2.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.no-cache">no-cache</a></li>
    616                            <li><a href="#rfc.section.7.2.1.5">7.2.1.5</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.no-store">no-store</a></li>
    617                            <li><a href="#rfc.section.7.2.1.6">7.2.1.6</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.no-transform">no-transform</a></li>
    618                            <li><a href="#rfc.section.7.2.1.7">7.2.1.7</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive.only-if-cached">only-if-cached</a></li>
    619                         </ul>
    620                      </li>
    621                      <li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a><ul>
    622                            <li><a href="#rfc.section.7.2.2.1">7.2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.must-revalidate">must-revalidate</a></li>
    623                            <li><a href="#rfc.section.7.2.2.2">7.2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.no-cache">no-cache</a></li>
    624                            <li><a href="#rfc.section.7.2.2.3">7.2.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.no-store">no-store</a></li>
    625                            <li><a href="#rfc.section.7.2.2.4">7.2.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.no-transform">no-transform</a></li>
    626                            <li><a href="#rfc.section.7.2.2.5">7.2.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.public">public</a></li>
    627                            <li><a href="#rfc.section.7.2.2.6">7.2.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.private">private</a></li>
    628                            <li><a href="#rfc.section.7.2.2.7">7.2.2.7</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></li>
    629                            <li><a href="#rfc.section.7.2.2.8">7.2.2.8</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.max-age">max-age</a></li>
    630                            <li><a href="#rfc.section.7.2.2.9">7.2.2.9</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive.s-maxage">s-maxage</a></li>
    631                         </ul>
    632                      </li>
    633                      <li><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li>
     652         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li>
     653         <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul>
     654               <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a><ul>
     655                     <li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></li>
     656                     <li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li>
     657                     <li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registration">Registrations</a></li>
    634658                  </ul>
    635659               </li>
    636                <li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li>
    637                <li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li>
    638                <li><a href="#rfc.section.7.5">7.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a><ul>
    639                      <li><a href="#rfc.section.7.5.1">7.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">110 Response is Stale</a></li>
    640                      <li><a href="#rfc.section.7.5.2">7.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">111 Revalidation Failed</a></li>
    641                      <li><a href="#rfc.section.7.5.3">7.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">112 Disconnected Operation</a></li>
    642                      <li><a href="#rfc.section.7.5.4">7.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">113 Heuristic Expiration</a></li>
    643                      <li><a href="#rfc.section.7.5.5">7.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">199 Miscellaneous Warning</a></li>
    644                      <li><a href="#rfc.section.7.5.6">7.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">214 Transformation Applied</a></li>
    645                      <li><a href="#rfc.section.7.5.7">7.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">299 Miscellaneous Persistent Warning</a></li>
    646                      <li><a href="#rfc.section.7.5.8">7.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.extensions">Warn Code Extensions</a></li>
     660               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry">Warn Code Registry</a><ul>
     661                     <li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></li>
     662                     <li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registration">Registrations</a></li>
    647663                  </ul>
    648664               </li>
     665               <li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    649666            </ul>
    650667         </li>
    651          <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li>
    652          <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul>
    653                <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a><ul>
    654                      <li><a href="#rfc.section.9.1.1">9.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></li>
    655                      <li><a href="#rfc.section.9.1.2">9.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li>
    656                      <li><a href="#rfc.section.9.1.3">9.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registration">Registrations</a></li>
    657                   </ul>
    658                </li>
    659                <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry">Warn Code Registry</a><ul>
    660                      <li><a href="#rfc.section.9.2.1">9.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></li>
    661                      <li><a href="#rfc.section.9.2.2">9.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registration">Registrations</a></li>
    662                   </ul>
    663                </li>
    664                <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    665             </ul>
    666          </li>
    667          <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
    668          <li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    669          <li><a href="#rfc.section.12">12.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    670                <li><a href="#rfc.section.12.1">12.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    671                <li><a href="#rfc.section.12.2">12.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     668         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
     669         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     670         <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     671               <li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     672               <li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    672673            </ul>
    673674         </li>
    … …  
    747748         <li>The request method is understood by the cache and defined as being cacheable, and</li>
    748749         <li>the response status code is understood by the cache, and</li>
    749          <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;7.2</a>) does not appear in request or response header fields, and
    750          </li>
    751          <li>the "private" cache response directive (see <a href="#cache-response-directive.private" title="private">Section&nbsp;7.2.2.6</a>) does not appear in the response, if the cache is shared, and
     750         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;5.2</a>) does not appear in request or response header fields, and
     751         </li>
     752         <li>the "private" cache response directive (see <a href="#cache-response-directive.private" title="private">Section&nbsp;5.2.2.6</a>) does not appear in the response, if the cache is shared, and
    752753         </li>
    753754         <li>the <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>), and
    … …  
    755756         <li>the response either:
    756757            <ul>
    757                <li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;7.3</a>), or
     758               <li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;5.3</a>), or
    758759               </li>
    759                <li>contains a max-age response cache directive (see <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>), or
     760               <li>contains a max-age response cache directive (see <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>), or
    760761               </li>
    761                <li>contains a s-maxage response cache directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.9</a>) and the cache is shared, or
     762               <li>contains a s-maxage response cache directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a>) and the cache is shared, or
    762763               </li>
    763                <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>) that allows it to be cached, or
     764               <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>) that allows it to be cached, or
    764765               </li>
    765766               <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>), or
    766767               </li>
    767                <li>contains a public response cache directive (see <a href="#cache-response-directive.public" title="public">Section&nbsp;7.2.2.5</a>).
     768               <li>contains a public response cache directive (see <a href="#cache-response-directive.public" title="public">Section&nbsp;5.2.2.5</a>).
    768769               </li>
    769770            </ul>
    770771         </li>
    771772      </ul>
    772       <p id="rfc.section.3.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>.
     773      <p id="rfc.section.3.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.
    773774      </p>
    774775      <p id="rfc.section.3.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all
    … …  
    789790      <p id="rfc.section.3.2.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
    790791      </p>
    791       <p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
     792      <p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
    792793      </p>
    793794      <p id="rfc.section.3.2.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be
    … …  
    803804      </p>
    804805      <ul>
    805          <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;7.5</a>);
     806         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;5.5</a>);
    806807         </li>
    807808         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
    … …  
    819820         <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), and
    820821         </li>
    821          <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;7.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and
    822          </li>
    823          <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;7.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and
     822         <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;5.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;5.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and
     823         </li>
     824         <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and
    824825         </li>
    825826         <li>the stored response is either:
    … …  
    834835         </li>
    835836      </ul>
    836       <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>.
    837       </p>
    838       <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.
     837      <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.
     838      </p>
     839      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;5.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.
    839840      </p>
    840841      <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
    841842         and having received a corresponding response.
    842843      </p>
    843       <p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;6</a>.
     844      <p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>.
    844845      </p>
    845846      <p id="rfc.section.4.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate
    … …  
    893894      </p>
    894895      <p id="rfc.section.4.2.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    895          using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;7.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
     896         using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;5.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
    896897         is not likely to change in a semantically significant way before the expiration time is reached.
    897898      </p>
    … …  
    908909      </p>
    909910      <p id="rfc.section.4.2.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the
    910          corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
     911         corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;5.2.1</a>).
    911912      </p>
    912913      <p id="rfc.section.4.2.p.11">When calculating freshness, to avoid common problems in date parsing:</p>
    … …  
    923924      </ul>
    924925      <p id="rfc.section.4.2.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
    925          a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;8</a> for an explanation of the difference between caches and history mechanisms.
     926         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;6</a> for an explanation of the difference between caches and history mechanisms.
    926927      </p>
    927928      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
    928929      <p id="rfc.section.4.2.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>
    929930      <ul>
    930          <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.9</a>) is present, use its value, or
    931          </li>
    932          <li>If the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>) is present, use its value, or
    933          </li>
    934          <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;7.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or
     931         <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a>) is present, use its value, or
     932         </li>
     933         <li>If the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>) is present, use its value, or
     934         </li>
     935         <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;5.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or
    935936         </li>
    936937         <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>.
    … …  
    973974      </p>
    974975      <ul class="empty">
    975          <li>The term "age_value" denotes the value of the <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;7.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
     976         <li>The term "age_value" denotes the value of the <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;5.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
    976977         </li>
    977978      </ul>
    … …  
    10251026      <p id="rfc.section.4.2.4.p.2">A cache <em class="bcp14">MUST NOT</em> generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    10261027         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    1027          see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>).
     1028         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>).
    10281029      </p>
    10291030      <p id="rfc.section.4.2.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
    1030          or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    1031       </p>
    1032       <p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
     1031         or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;5.2.1</a>).
     1032      </p>
     1033      <p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;5.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
    10331034      </p>
    10341035      <div id="rfc.iref.f.3"></div>
    … …  
    10381039      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="validation.model" href="#validation.model">Validation</a></h2>
    10391040      <p id="rfc.section.4.3.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not
    1040          fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
    1041          update it. This process is known as "validating" or "revalidating" the stored response.
     1041         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the next inbound server an opportunity to select a valid stored response to use, updating
     1042         the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as "validating"
     1043         or "revalidating" the stored response.
    10421044      </p>
    10431045      <div id="rfc.iref.v.1"></div>
    1044       <p id="rfc.section.4.3.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of
    1045          the resource.
    1046       </p>
    1047       <p id="rfc.section.4.3.p.3">One such validator is the <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field, whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>) stored response, if available.
    1048       </p>
    1049       <p id="rfc.section.4.3.p.4">Another is the <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field, whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from relevant responses stored for the primary cache key, if present. However, if any of the stored responses
    1050          contains only partial content, the cache ought not include its entity-tag in the If-None-Match header field unless the request
    1051          is for a range that would be fully satisfied by that stored response.
    1052       </p>
    1053       <p id="rfc.section.4.3.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p>
    1054       <p id="rfc.section.4.3.p.6"></p>
     1046      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="validation.sent" href="#validation.sent">Sending a Validation Request</a></h3>
     1047      <p id="rfc.section.4.3.1.p.1">When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing <dfn>validator</dfn> metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent
     1048         to a current representation of the resource.
     1049      </p>
     1050      <p id="rfc.section.4.3.1.p.2">One such validator is the timestamp given in a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), which can be used in an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field for response validation, or in an <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field for representation selection (i.e., the client is referring specifically to a previously obtained representation
     1051         with that timestamp).
     1052      </p>
     1053      <p id="rfc.section.4.3.1.p.3">Another validator is the entity-tag given in an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). One or more entity-tags, indicating one or more stored responses, can be used in an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field for response validation, or in an <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a> or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field for representation selection (i.e., the client is referring specifically to one or more previously obtained representations
     1054         with the listed entity-tags).
     1055      </p>
     1056      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="validation.received" href="#validation.received">Handling a Received Validation Request</a></h3>
     1057      <p id="rfc.section.4.3.2.p.1">Each client in the request chain may have its own cache, so it is common for a cache at an intermediary or origin server to
     1058         receive conditional requests from other (outbound) caches. Likewise, some user agents make use of conditional requests to
     1059         limit data transfers to recently modified representations or to complete the transfer of partially retrieved representations.
     1060      </p>
     1061      <p id="rfc.section.4.3.2.p.2">If the request semantics can be satisfied with a cached response and a recipient cache has at least one response stored for
     1062         this primary cache key, the cache <em class="bcp14">MUST</em> evaluate received precondition header fields as part of its selection process for determining a suitable response. A cache <em class="bcp14">MUST NOT</em> evaluate received precondition header fields in a request with semantics that cannot be satisfied with a cached response,
     1063         or for which the cache has no prior stored responses, since such preconditions are intended for some other (inbound) server.
     1064      </p>
     1065      <p id="rfc.section.4.3.2.p.3">The proper evaluation of conditional requests by a cache depends on the received precondition header fields and their precedence,
     1066         as defined in <a href="p4-conditional.html#precedence" title="Precedence">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
     1067      </p>
     1068      <p id="rfc.section.4.3.2.p.4">A request containing an <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a> header field (<a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to receive an error response if the cache has a stored response that cannot be used to answer
     1069         this request. The cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.412" class="smpl">412 (Precondition Failed)</a> response if the field-value is "*" and no suitable response is stored, or if the field-value is a list of entity-tags and
     1070         none of them match the entity-tag of a suitable stored response. Otherwise, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most recent of its matching stored responses to satisfy the request.
     1071      </p>
     1072      <p id="rfc.section.4.3.2.p.5">A request containing an <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field (<a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to receive an error response if the cache has a stored response that cannot be used to answer
     1073         this request. The cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.412" class="smpl">412 (Precondition Failed)</a> response if one of the following is true: 1) a stored response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.
     1074         Otherwise, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most recent of its matching stored responses to satisfy the request.
     1075      </p>
     1076      <p id="rfc.section.4.3.2.p.6">A request containing an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field (<a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to validate one or more of its stored responses. If the field-value is "*" and any suitable
     1077         response is stored, or the field-value is a list of entity-tags and at least one of them match the entity-tag of a suitable
     1078         stored response, the cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response using the most suitable of those matching responses as the selected representation. Otherwise, if the cache has one
     1079         or more suitable stored responses that do not match the condition, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most suitable of those stored responses to satisfy the request. Finally, if the cache has no suitable
     1080         stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server; if the received condition contains a list of entity-tags and the
     1081         cache has its own set of stored responses for that primary cache key, the cache <em class="bcp14">SHOULD</em> take the union of the received set with the set of entity-tags for its own stored set of responses (fresh or stale) and generate
     1082         an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field containing that union when it forwards the request toward the origin server. However, if a stored responses contains
     1083         only partial content, the cache <em class="bcp14">MUST NOT</em> include its entity-tag in the union unless the request is for a range that would be fully satisfied by that stored response.
     1084      </p>
     1085      <p id="rfc.section.4.3.2.p.7">A request containing an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field (<a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to validate one or more of its stored responses by modification date if the stored responses
     1086         have no entity-tag or the recipient does not implement <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>. The cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response, reusing the most recent of its stored responses to satisfy the request, if one of the following is true: 1) a stored
     1087         response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.
     1088         Otherwise, if the cache has one or more suitable stored responses, the cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response using the most recent of its suitable stored responses as the selected representation. Finally, if the cache has
     1089         no suitable stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server.
     1090      </p>
     1091      <p id="rfc.section.4.3.2.p.8">A cache that implements partial responses to range requests, as defined in <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, also needs to evaluate a received <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) in respect to its selected stored response.
     1092      </p>
     1093      <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;<a id="validation.response" href="#validation.response">Handling a Validation Response</a></h3>
     1094      <p id="rfc.section.4.3.3.p.1">Cache handling of a response to a conditional request is dependent upon its status code:</p>
     1095      <p id="rfc.section.4.3.3.p.2"></p>
    10551096      <ul>
    1056          <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section&nbsp;4.3.1</a>.
     1097         <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section&nbsp;4.3.4</a>.
    10571098         </li>
    10581099         <li>A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request
    1059             is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
     1100            is suitable. Instead, the cache <em class="bcp14">MUST</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
    10601101         </li>
    10611102         <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as
    1062             if the server failed to respond. In the latter case, it can send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).
    1063          </li>
    1064       </ul>
    1065       <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>
    1066       <p id="rfc.section.4.3.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response
     1103            if the server failed to respond. In the latter case, the cache <em class="bcp14">MAY</em> send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).
     1104         </li>
     1105      </ul>
     1106      <h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>
     1107      <p id="rfc.section.4.3.4.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response
    10671108         and then update the stored response(s) with the new information provided in the <a href="p4-conditional.html#status.304" class="smpl">304</a> response.
    10681109      </p>
    10691110      <div id="rfc.iref.s.3"></div>
    1070       <p id="rfc.section.4.3.1.p.2">The stored response to update is identified by using the first match (if any) of: </p>
     1111      <p id="rfc.section.4.3.4.p.2">The stored response to update is identified by using the first match (if any) of: </p>
    10711112      <ul>
    1072          <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same
     1113         <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same
    10731114            strong validator are selected. If none of the stored responses contain the same strong validator, then the cache <em class="bcp14">MUST NOT</em> use the new response to update any stored responses.
    10741115         </li>
    … …  
    10811122         </li>
    10821123      </ul>
    1083       <p id="rfc.section.4.3.1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:
     1124      <p id="rfc.section.4.3.4.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:
    10841125      </p>
    10851126      <ul>
    1086          <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;7.5</a>);
     1127         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;5.5</a>);
    10871128         </li>
    10881129         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
    … …  
    10911132         </li>
    10921133      </ul>
    1093       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="head.effects" href="#head.effects">Updating Caches with HEAD Responses</a></h1>
    1094       <p id="rfc.section.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks
    1095          a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
    1096       </p>
    1097       <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
    1098       </p>
    1099       <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules:
     1134      <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="head.effects" href="#head.effects">Freshening Responses via HEAD</a></h3>
     1135      <p id="rfc.section.4.3.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks
     1136         a body. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional
     1137         GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the
     1138         representation body is not desired even if it has changed.
     1139      </p>
     1140      <p id="rfc.section.4.3.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
     1141      </p>
     1142      <p id="rfc.section.4.3.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules:
    11001143      </p>
    11011144      <ul>
    1102          <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;7.5</a>);
     1145         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;5.5</a>);
    11031146         </li>
    11041147         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
    11051148         </li>
    1106          <li>use other header fields provided in the response to replace all instances of the corresponding header fields in the stored
     1149         <li>use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored
    11071150            response.
    11081151         </li>
    11091152      </ul>
    1110       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1>
    1111       <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
     1153      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="invalidation" href="#invalidation">Invalidation</a></h2>
     1154      <p id="rfc.section.4.4.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
    11121155         to keep their contents up-to-date.
    11131156      </p>
    1114       <p id="rfc.section.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
    1115       </p>
    1116       <p id="rfc.section.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    1117       </p>
    1118       <p id="rfc.section.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
    1119       </p>
    1120       <p id="rfc.section.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,
     1157      <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
     1158      </p>
     1159      <p id="rfc.section.4.4.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks.
     1160      </p>
     1161      <p id="rfc.section.4.4.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
     1162      </p>
     1163      <p id="rfc.section.4.4.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,
    11211164         or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent
    11221165         request.
    11231166      </p>
    1124       <p id="rfc.section.6.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might
     1167      <p id="rfc.section.4.4.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might
    11251168         invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it
    11261169         has not.
    11271170      </p>
    1128       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    1129       <p id="rfc.section.7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
     1171      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     1172      <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    11301173      <div id="rfc.iref.a.2"></div>
    1131       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
    1132       <p id="rfc.section.7.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully
     1174      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
     1175      <p id="rfc.section.5.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully
    11331176         validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.
    11341177      </p>
    11351178      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a> = <a href="#delta-seconds" class="smpl">delta-seconds</a>
    1136 </pre><p id="rfc.section.7.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>).
    1137       </p>
    1138       <p id="rfc.section.7.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
     1179</pre><p id="rfc.section.5.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>).
     1180      </p>
     1181      <p id="rfc.section.5.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
    11391182         true, since HTTP/1.0 caches might not implement the Age header field.
    11401183      </p>
    11411184      <div id="rfc.iref.c.5"></div>
    1142       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    1143       <p id="rfc.section.7.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives
     1185      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
     1186      <p id="rfc.section.5.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives
    11441187         are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given
    11451188         in the response.
    11461189      </p>
    1147       <p id="rfc.section.7.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.
    1148       </p>
    1149       <div class="note" id="rfc.section.7.2.p.3">
     1190      <p id="rfc.section.5.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.
     1191      </p>
     1192      <div class="note" id="rfc.section.5.2.p.3">
    11501193         <p><b>Note:</b> Some HTTP/1.0 caches might not implement Cache-Control.
    11511194         </p>
    11521195      </div>
    1153       <p id="rfc.section.7.2.p.4">A proxy, whether or not it implements a cache, <em class="bcp14">MUST</em> pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives
     1196      <p id="rfc.section.5.2.p.4">A proxy, whether or not it implements a cache, <em class="bcp14">MUST</em> pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives
    11541197         might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific
    11551198         cache.
    11561199      </p>
    1157       <p id="rfc.section.7.2.p.5">Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use
     1200      <p id="rfc.section.5.2.p.5">Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use
    11581201         both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both
    11591202         forms, even if one is documented to be preferred. For any directive not defined by this specification, recipients <em class="bcp14">MUST</em> accept both forms.
    … …  
    11621205
    11631206  <a href="#header.cache-control" class="smpl">cache-directive</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ]
    1164 </pre><p id="rfc.section.7.2.p.7">For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.</p>
    1165       <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
     1207</pre><p id="rfc.section.5.2.p.7">For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.</p>
     1208      <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
    11661209      <div id="rfc.iref.m.1"></div>
    1167       <h4 id="rfc.section.7.2.1.1"><a href="#rfc.section.7.2.1.1">7.2.1.1</a>&nbsp;<a id="cache-request-directive.max-age" href="#cache-request-directive.max-age">max-age</a></h4>
    1168       <p id="rfc.section.7.2.1.1.p.1">Argument syntax: </p>
     1210      <h4 id="rfc.section.5.2.1.1"><a href="#rfc.section.5.2.1.1">5.2.1.1</a>&nbsp;<a id="cache-request-directive.max-age" href="#cache-request-directive.max-age">max-age</a></h4>
     1211      <p id="rfc.section.5.2.1.1.p.1">Argument syntax: </p>
    11691212      <ul class="empty">
    11701213         <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    11711214         </li>
    11721215      </ul>
    1173       <p id="rfc.section.7.2.1.1.p.2">The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the
     1216      <p id="rfc.section.5.2.1.1.p.2">The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the
    11741217         specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a
    11751218         stale response.
    11761219      </p>
    1177       <p id="rfc.section.7.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1220      <p id="rfc.section.5.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
    11781221      </p>
    11791222      <div id="rfc.iref.m.2"></div>
    1180       <h4 id="rfc.section.7.2.1.2"><a href="#rfc.section.7.2.1.2">7.2.1.2</a>&nbsp;<a id="cache-request-directive.max-stale" href="#cache-request-directive.max-stale">max-stale</a></h4>
    1181       <p id="rfc.section.7.2.1.2.p.1">Argument syntax: </p>
     1223      <h4 id="rfc.section.5.2.1.2"><a href="#rfc.section.5.2.1.2">5.2.1.2</a>&nbsp;<a id="cache-request-directive.max-stale" href="#cache-request-directive.max-stale">max-stale</a></h4>
     1224      <p id="rfc.section.5.2.1.2.p.1">Argument syntax: </p>
    11821225      <ul class="empty">
    11831226         <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    11841227         </li>
    11851228      </ul>
    1186       <p id="rfc.section.7.2.1.2.p.2">The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness
     1229      <p id="rfc.section.5.2.1.2.p.2">The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness
    11871230         lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness
    11881231         lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing
    11891232         to accept a stale response of any age.
    11901233      </p>
    1191       <p id="rfc.section.7.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1234      <p id="rfc.section.5.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
    11921235      </p>
    11931236      <div id="rfc.iref.m.3"></div>
    1194       <h4 id="rfc.section.7.2.1.3"><a href="#rfc.section.7.2.1.3">7.2.1.3</a>&nbsp;<a id="cache-request-directive.min-fresh" href="#cache-request-directive.min-fresh">min-fresh</a></h4>
    1195       <p id="rfc.section.7.2.1.3.p.1">Argument syntax: </p>
     1237      <h4 id="rfc.section.5.2.1.3"><a href="#rfc.section.5.2.1.3">5.2.1.3</a>&nbsp;<a id="cache-request-directive.min-fresh" href="#cache-request-directive.min-fresh">min-fresh</a></h4>
     1238      <p id="rfc.section.5.2.1.3.p.1">Argument syntax: </p>
    11961239      <ul class="empty">
    11971240         <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    11981241         </li>
    11991242      </ul>
    1200       <p id="rfc.section.7.2.1.3.p.2">The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no
     1243      <p id="rfc.section.5.2.1.3.p.2">The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no
    12011244         less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh
    12021245         for at least the specified number of seconds.
    12031246      </p>
    1204       <p id="rfc.section.7.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1247      <p id="rfc.section.5.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
    12051248      </p>
    12061249      <div id="rfc.iref.n.1"></div>
    1207       <h4 id="rfc.section.7.2.1.4"><a href="#rfc.section.7.2.1.4">7.2.1.4</a>&nbsp;<a id="cache-request-directive.no-cache" href="#cache-request-directive.no-cache">no-cache</a></h4>
    1208       <p id="rfc.section.7.2.1.4.p.1">The "no-cache" request directive indicates that a cache <em class="bcp14">MUST NOT</em> use a stored response to satisfy the request without successful validation on the origin server.
     1250      <h4 id="rfc.section.5.2.1.4"><a href="#rfc.section.5.2.1.4">5.2.1.4</a>&nbsp;<a id="cache-request-directive.no-cache" href="#cache-request-directive.no-cache">no-cache</a></h4>
     1251      <p id="rfc.section.5.2.1.4.p.1">The "no-cache" request directive indicates that a cache <em class="bcp14">MUST NOT</em> use a stored response to satisfy the request without successful validation on the origin server.
    12091252      </p>
    12101253      <div id="rfc.iref.n.2"></div>
    1211       <h4 id="rfc.section.7.2.1.5"><a href="#rfc.section.7.2.1.5">7.2.1.5</a>&nbsp;<a id="cache-request-directive.no-store" href="#cache-request-directive.no-store">no-store</a></h4>
    1212       <p id="rfc.section.7.2.1.5.p.1">The "no-store" request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
    1213       </p>
    1214       <p id="rfc.section.7.2.1.5.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
     1254      <h4 id="rfc.section.5.2.1.5"><a href="#rfc.section.5.2.1.5">5.2.1.5</a>&nbsp;<a id="cache-request-directive.no-store" href="#cache-request-directive.no-store">no-store</a></h4>
     1255      <p id="rfc.section.5.2.1.5.p.1">The "no-store" request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
     1256      </p>
     1257      <p id="rfc.section.5.2.1.5.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
    12151258         might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
    12161259      </p>
    1217       <p id="rfc.section.7.2.1.5.p.3">Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply
     1260      <p id="rfc.section.5.2.1.5.p.3">Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply
    12181261         to the already stored response.
    12191262      </p>
    12201263      <div id="rfc.iref.n.3"></div>
    1221       <h4 id="rfc.section.7.2.1.6"><a href="#rfc.section.7.2.1.6">7.2.1.6</a>&nbsp;<a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4>
    1222       <p id="rfc.section.7.2.1.6.p.1">The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     1264      <h4 id="rfc.section.5.2.1.6"><a href="#rfc.section.5.2.1.6">5.2.1.6</a>&nbsp;<a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4>
     1265      <p id="rfc.section.5.2.1.6.p.1">The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    12231266      </p>
    12241267      <div id="rfc.iref.o.1"></div>
    1225       <h4 id="rfc.section.7.2.1.7"><a href="#rfc.section.7.2.1.7">7.2.1.7</a>&nbsp;<a id="cache-request-directive.only-if-cached" href="#cache-request-directive.only-if-cached">only-if-cached</a></h4>
    1226       <p id="rfc.section.7.2.1.7.p.1">The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this
     1268      <h4 id="rfc.section.5.2.1.7"><a href="#rfc.section.5.2.1.7">5.2.1.7</a>&nbsp;<a id="cache-request-directive.only-if-cached" href="#cache-request-directive.only-if-cached">only-if-cached</a></h4>
     1269      <p id="rfc.section.5.2.1.7.p.1">The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this
    12271270         directive, a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a <a href="p2-semantics.html#status.504" class="smpl">504 (Gateway
    12281271            Timeout)</a> status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache <em class="bcp14">MAY</em> forward such a request within that group of caches.
    12291272      </p>
    1230       <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
     1273      <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
    12311274      <div id="rfc.iref.m.4"></div>
    1232       <h4 id="rfc.section.7.2.2.1"><a href="#rfc.section.7.2.2.1">7.2.2.1</a>&nbsp;<a id="cache-response-directive.must-revalidate" href="#cache-response-directive.must-revalidate">must-revalidate</a></h4>
    1233       <p id="rfc.section.7.2.2.1.p.1">The "must-revalidate" response directive indicates that once it has become stale, a cache <em class="bcp14">MUST NOT</em> use the response to satisfy subsequent requests without successful validation on the origin server.
    1234       </p>
    1235       <p id="rfc.section.7.2.2.1.p.2">The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
     1275      <h4 id="rfc.section.5.2.2.1"><a href="#rfc.section.5.2.2.1">5.2.2.1</a>&nbsp;<a id="cache-response-directive.must-revalidate" href="#cache-response-directive.must-revalidate">must-revalidate</a></h4>
     1276      <p id="rfc.section.5.2.2.1.p.1">The "must-revalidate" response directive indicates that once it has become stale, a cache <em class="bcp14">MUST NOT</em> use the response to satisfy subsequent requests without successful validation on the origin server.
     1277      </p>
     1278      <p id="rfc.section.5.2.2.1.p.2">The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
    12361279         a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.504" class="smpl">504 (Gateway Timeout)</a> response.
    12371280      </p>
    1238       <p id="rfc.section.7.2.2.1.p.3">The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation
     1281      <p id="rfc.section.5.2.2.1.p.3">The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation
    12391282         could result in incorrect operation, such as a silently unexecuted financial transaction.
    12401283      </p>
    12411284      <div id="rfc.iref.n.4"></div>
    1242       <h4 id="rfc.section.7.2.2.2"><a href="#rfc.section.7.2.2.2">7.2.2.2</a>&nbsp;<a id="cache-response-directive.no-cache" href="#cache-response-directive.no-cache">no-cache</a></h4>
    1243       <p id="rfc.section.7.2.2.2.p.1">Argument syntax: </p>
     1285      <h4 id="rfc.section.5.2.2.2"><a href="#rfc.section.5.2.2.2">5.2.2.2</a>&nbsp;<a id="cache-response-directive.no-cache" href="#cache-response-directive.no-cache">no-cache</a></h4>
     1286      <p id="rfc.section.5.2.2.2.p.1">Argument syntax: </p>
    12441287      <ul class="empty">
    12451288         <li>#<a href="#imported.abnf" class="smpl">field-name</a>
    12461289         </li>
    12471290      </ul>
    1248       <p id="rfc.section.7.2.2.2.p.2">The "no-cache" response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to
     1291      <p id="rfc.section.5.2.2.2.p.2">The "no-cache" response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to
    12491292         prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send
    12501293         stale responses.
    12511294      </p>
    1252       <p id="rfc.section.7.2.2.2.p.3">If the no-cache response directive specifies one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields
     1295      <p id="rfc.section.5.2.2.2.p.3">If the no-cache response directive specifies one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields
    12531296         in the response that have the field-name(s) listed <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin
    12541297         server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
    12551298      </p>
    1256       <p id="rfc.section.7.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
    1257       <p id="rfc.section.7.2.2.2.p.5"><b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive.
     1299      <p id="rfc.section.5.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
     1300      <p id="rfc.section.5.2.2.2.p.5"><b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive.
    12581301         Also, no-cache response directives with field-names are often handled by caches as if an unqualified no-cache directive was
    12591302         received; i.e., the special handling for the qualified form is not widely implemented.
    12601303      </p>
    1261       <p id="rfc.section.7.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     1304      <p id="rfc.section.5.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
    12621305      </p>
    12631306      <div id="rfc.iref.n.5"></div>
    1264       <h4 id="rfc.section.7.2.2.3"><a href="#rfc.section.7.2.2.3">7.2.2.3</a>&nbsp;<a id="cache-response-directive.no-store" href="#cache-response-directive.no-store">no-store</a></h4>
    1265       <p id="rfc.section.7.2.2.3.p.1">The "no-store" response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
    1266       </p>
    1267       <p id="rfc.section.7.2.2.3.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
     1307      <h4 id="rfc.section.5.2.2.3"><a href="#rfc.section.5.2.2.3">5.2.2.3</a>&nbsp;<a id="cache-response-directive.no-store" href="#cache-response-directive.no-store">no-store</a></h4>
     1308      <p id="rfc.section.5.2.2.3.p.1">The "no-store" response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
     1309      </p>
     1310      <p id="rfc.section.5.2.2.3.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
    12681311         might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
    12691312      </p>
    12701313      <div id="rfc.iref.n.6"></div>
    1271       <h4 id="rfc.section.7.2.2.4"><a href="#rfc.section.7.2.2.4">7.2.2.4</a>&nbsp;<a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4>
    1272       <p id="rfc.section.7.2.2.4.p.1">The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     1314      <h4 id="rfc.section.5.2.2.4"><a href="#rfc.section.5.2.2.4">5.2.2.4</a>&nbsp;<a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4>
     1315      <p id="rfc.section.5.2.2.4.p.1">The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    12731316      </p>
    12741317      <div id="rfc.iref.p.2"></div>
    1275       <h4 id="rfc.section.7.2.2.5"><a href="#rfc.section.7.2.2.5">7.2.2.5</a>&nbsp;<a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4>
    1276       <p id="rfc.section.7.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined
     1318      <h4 id="rfc.section.5.2.2.5"><a href="#rfc.section.5.2.2.5">5.2.2.5</a>&nbsp;<a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4>
     1319      <p id="rfc.section.5.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined
    12771320         as cacheable.)
    12781321      </p>
    12791322      <div id="rfc.iref.p.3"></div>
    1280       <h4 id="rfc.section.7.2.2.6"><a href="#rfc.section.7.2.2.6">7.2.2.6</a>&nbsp;<a id="cache-response-directive.private" href="#cache-response-directive.private">private</a></h4>
    1281       <p id="rfc.section.7.2.2.6.p.1">Argument syntax: </p>
     1323      <h4 id="rfc.section.5.2.2.6"><a href="#rfc.section.5.2.2.6">5.2.2.6</a>&nbsp;<a id="cache-response-directive.private" href="#cache-response-directive.private">private</a></h4>
     1324      <p id="rfc.section.5.2.2.6.p.1">Argument syntax: </p>
    12821325      <ul class="empty">
    12831326         <li>#<a href="#imported.abnf" class="smpl">field-name</a>
    12841327         </li>
    12851328      </ul>
    1286       <p id="rfc.section.7.2.2.6.p.2">The "private" response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private cache <em class="bcp14">MAY</em> store the response and reuse it for later requests, even if the response would normally be non-cacheable.
    1287       </p>
    1288       <p id="rfc.section.7.2.2.6.p.3">If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated
     1329      <p id="rfc.section.5.2.2.6.p.2">The "private" response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private cache <em class="bcp14">MAY</em> store the response and reuse it for later requests, even if the response would normally be non-cacheable.
     1330      </p>
     1331      <p id="rfc.section.5.2.2.6.p.3">If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated
    12891332         with the listed response header fields. That is, a shared cache <em class="bcp14">MUST NOT</em> store the specified field-names(s), whereas it <em class="bcp14">MAY</em> store the remainder of the response message.
    12901333      </p>
    1291       <p id="rfc.section.7.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
    1292       <p id="rfc.section.7.2.2.6.p.5"><b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message
     1334      <p id="rfc.section.5.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
     1335      <p id="rfc.section.5.2.2.6.p.5"><b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message
    12931336         content. Also, private response directives with field-names are often handled by caches as if an unqualified private directive
    12941337         was received; i.e., the special handling for the qualified form is not widely implemented.
    12951338      </p>
    1296       <p id="rfc.section.7.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     1339      <p id="rfc.section.5.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
    12971340      </p>
    12981341      <div id="rfc.iref.p.4"></div>
    1299       <h4 id="rfc.section.7.2.2.7"><a href="#rfc.section.7.2.2.7">7.2.2.7</a>&nbsp;<a id="cache-response-directive.proxy-revalidate" href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></h4>
    1300       <p id="rfc.section.7.2.2.7.p.1">The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does
     1342      <h4 id="rfc.section.5.2.2.7"><a href="#rfc.section.5.2.2.7">5.2.2.7</a>&nbsp;<a id="cache-response-directive.proxy-revalidate" href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></h4>
     1343      <p id="rfc.section.5.2.2.7.p.1">The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does
    13011344         not apply to private caches.
    13021345      </p>
    13031346      <div id="rfc.iref.m.5"></div>
    1304       <h4 id="rfc.section.7.2.2.8"><a href="#rfc.section.7.2.2.8">7.2.2.8</a>&nbsp;<a id="cache-response-directive.max-age" href="#cache-response-directive.max-age">max-age</a></h4>
    1305       <p id="rfc.section.7.2.2.8.p.1">Argument syntax: </p>
     1347      <h4 id="rfc.section.5.2.2.8"><a href="#rfc.section.5.2.2.8">5.2.2.8</a>&nbsp;<a id="cache-response-directive.max-age" href="#cache-response-directive.max-age">max-age</a></h4>
     1348      <p id="rfc.section.5.2.2.8.p.1">Argument syntax: </p>
    13061349      <ul class="empty">
    13071350         <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    13081351         </li>
    13091352      </ul>
    1310       <p id="rfc.section.7.2.2.8.p.2">The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified
     1353      <p id="rfc.section.5.2.2.8.p.2">The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified
    13111354         number of seconds.
    13121355      </p>
    1313       <p id="rfc.section.7.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1356      <p id="rfc.section.5.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
    13141357      </p>
    13151358      <div id="rfc.iref.s.4"></div>
    1316       <h4 id="rfc.section.7.2.2.9"><a href="#rfc.section.7.2.2.9">7.2.2.9</a>&nbsp;<a id="cache-response-directive.s-maxage" href="#cache-response-directive.s-maxage">s-maxage</a></h4>
    1317       <p id="rfc.section.7.2.2.9.p.1">Argument syntax: </p>
     1359      <h4 id="rfc.section.5.2.2.9"><a href="#rfc.section.5.2.2.9">5.2.2.9</a>&nbsp;<a id="cache-response-directive.s-maxage" href="#cache-response-directive.s-maxage">s-maxage</a></h4>
     1360      <p id="rfc.section.5.2.2.9.p.1">Argument syntax: </p>
    13181361      <ul class="empty">
    13191362         <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    13201363         </li>
    13211364      </ul>
    1322       <p id="rfc.section.7.2.2.9.p.2">The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides
     1365      <p id="rfc.section.5.2.2.9.p.2">The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides
    13231366         the maximum age specified by either the max-age directive or the <a href="#header.expires" class="smpl">Expires</a> header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
    13241367      </p>
    1325       <p id="rfc.section.7.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
    1326       </p>
    1327       <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
    1328       <p id="rfc.section.7.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
     1368      <p id="rfc.section.5.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1369      </p>
     1370      <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
     1371      <p id="rfc.section.5.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
    13291372         value.
    13301373      </p>
    1331       <p id="rfc.section.7.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics
     1374      <p id="rfc.section.5.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics
    13321375         of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives.
    13331376      </p>
    1334       <p id="rfc.section.7.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive
     1377      <p id="rfc.section.5.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive
    13351378         will default to the behavior specified by the standard directive, and those that understand the new directive will recognize
    13361379         it as modifying the requirements associated with the standard directive. In this way, extensions to the cache-control directives
    13371380         can be made without requiring changes to the base protocol.
    13381381      </p>
    1339       <p id="rfc.section.7.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
     1382      <p id="rfc.section.5.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
    13401383         obeying certain extensions, and ignoring all directives that it does not understand.
    13411384      </p>
    1342       <p id="rfc.section.7.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
     1385      <p id="rfc.section.5.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
    13431386         We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the
    13441387         community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to
    … …  
    13461389      </p>
    13471390      <div id="rfc.figure.u.8"></div><pre class="text">  Cache-Control: private, community="UCI"
    1348 </pre><p id="rfc.section.7.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
     1391</pre><p id="rfc.section.5.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
    13491392         it will also see and understand the private directive and thus default to the safe behavior.
    13501393      </p>
    1351       <p id="rfc.section.7.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
     1394      <p id="rfc.section.5.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
    13521395         will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain
    13531396         minimally correct even if the cache does not understand the extension(s).
    13541397      </p>
    13551398      <div id="rfc.iref.e.2"></div>
    1356       <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
    1357       <p id="rfc.section.7.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a> for further discussion of the freshness model.
    1358       </p>
    1359       <p id="rfc.section.7.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
     1399      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
     1400      <p id="rfc.section.5.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a> for further discussion of the freshness model.
     1401      </p>
     1402      <p id="rfc.section.5.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
    13601403         that time.
    13611404      </p>
    1362       <p id="rfc.section.7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     1405      <p id="rfc.section.5.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    13631406      </p>
    13641407      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    13651408</pre><div id="rfc.figure.u.10"></div>
    13661409      <p>For example</p><pre class="text">  Expires: Thu, 01 Dec 1994 16:00:00 GMT
    1367 </pre><p id="rfc.section.7.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
    1368       </p>
    1369       <p id="rfc.section.7.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.9</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented
     1410</pre><p id="rfc.section.5.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
     1411      </p>
     1412      <p id="rfc.section.5.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented
    13701413         the Cache-Control field.
    13711414      </p>
    1372       <p id="rfc.section.7.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated
     1415      <p id="rfc.section.5.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated
    13731416         with the resource by a system or user with a reliable clock.
    13741417      </p>
    1375       <p id="rfc.section.7.3.p.9">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
     1418      <p id="rfc.section.5.3.p.9">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
    13761419         are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use
    13771420         of 32-bit integers for time values), and many caches will evict a response far sooner than that.
    13781421      </p>
    13791422      <div id="rfc.iref.p.5"></div>
    1380       <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
    1381       <p id="rfc.section.7.4.p.1">The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request
     1423      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
     1424      <p id="rfc.section.5.4.p.1">The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request
    13821425         that they will understand (as <a href="#header.cache-control" class="smpl">Cache-Control</a> was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is
    13831426         ignored.
    13841427      </p>
    1385       <p id="rfc.section.7.4.p.2">In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification
     1428      <p id="rfc.section.5.4.p.2">In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification
    13861429         deprecates such extensions to improve interoperability.
    13871430      </p>
    … …  
    13891432  <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
    13901433  <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ]
    1391 </pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    1392       </p>
    1393       <p id="rfc.section.7.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
     1434</pre><p id="rfc.section.5.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;5.2.1</a>).
     1435      </p>
     1436      <p id="rfc.section.5.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
    13941437         no-cache is purposefully omitted to target other <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives at HTTP/1.1 caches. For example:
    13951438      </p>
    … …  
    13991442Pragma: no-cache
    14001443
    1401 </pre><p id="rfc.section.7.4.p.7">will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not
     1444</pre><p id="rfc.section.5.4.p.7">will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not
    14021445         understand <a href="#header.cache-control" class="smpl">Cache-Control</a> from serving a cached response.
    14031446      </p>
    1404       <div class="note" id="rfc.section.7.4.p.8">
     1447      <div class="note" id="rfc.section.5.4.p.8">
    14051448         <p><b>Note:</b> Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control:
    14061449            no-cache" in them.
    … …  
    14081451      </div>
    14091452      <div id="rfc.iref.w.1"></div>
    1410       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
    1411       <p id="rfc.section.7.5.p.1">The "Warning" header field is used to carry additional information about the status or transformation of a message that might
     1453      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
     1454      <p id="rfc.section.5.5.p.1">The "Warning" header field is used to carry additional information about the status or transformation of a message that might
    14121455         not be reflected in the message. This information is typically used to warn about possible incorrectness introduced by caching
    14131456         operations or transformations applied to the payload of the message.
    14141457      </p>
    1415       <p id="rfc.section.7.5.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
     1458      <p id="rfc.section.5.5.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
    14161459         code, distinguishes these responses from true failures.
    14171460      </p>
    1418       <p id="rfc.section.7.5.p.3">Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only
     1461      <p id="rfc.section.5.5.p.3">Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only
    14191462         be applied to response messages.
    14201463      </p>
    … …  
    14301473  <a href="#header.warning" class="smpl">warn-text</a>  = <a href="#imported.abnf" class="smpl">quoted-string</a>
    14311474  <a href="#header.warning" class="smpl">warn-date</a>  = <a href="#imported.abnf" class="smpl">DQUOTE</a> <a href="#imported.abnf" class="smpl">HTTP-date</a> <a href="#imported.abnf" class="smpl">DQUOTE</a>
    1432 </pre><p id="rfc.section.7.5.p.5">Multiple warnings can be attached to a response (either by the origin server or by a cache), including multiple warnings with
     1475</pre><p id="rfc.section.5.5.p.5">Multiple warnings can be attached to a response (either by the origin server or by a cache), including multiple warnings with
    14331476         the same code number, only differing in warn-text.
    14341477      </p>
    1435       <p id="rfc.section.7.5.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.
    1436       </p>
    1437       <p id="rfc.section.7.5.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New
     1478      <p id="rfc.section.5.5.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.
     1479      </p>
     1480      <p id="rfc.section.5.5.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New
    14381481         Warning header fields are added after any existing Warning header fields.
    14391482      </p>
    1440       <p id="rfc.section.7.5.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
     1483      <p id="rfc.section.5.5.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
    14411484         a stored response after validation:
    14421485      </p>
    … …  
    14481491         </li>
    14491492      </ul>
    1450       <p id="rfc.section.7.5.p.9">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Thus, Warnings in responses
     1493      <p id="rfc.section.5.5.p.9">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Thus, Warnings in responses
    14511494         carry a warning-date field, which can help in detecting an erroneously cached Warning.
    14521495      </p>
    1453       <p id="rfc.section.7.5.p.10">RFC 2616 made the Warning header field's warn-date component optional; it was only required to be sent when the recipient's
     1496      <p id="rfc.section.5.5.p.10">RFC 2616 made the Warning header field's warn-date component optional; it was only required to be sent when the recipient's
    14541497         version was HTTP/1.0 or lower. However, deployment experience has shown that many intermediaries do not process the Warning
    14551498         header field as required by RFC 2616. This results in situations where the field can appear in messages where it is not applicable,
    14561499         because a warning-value has not been removed by an intermediary.
    14571500      </p>
    1458       <p id="rfc.section.7.5.p.11">As a result, this specification shifts responsibility for processing of Warning from intermediaries to the recipient that
     1501      <p id="rfc.section.5.5.p.11">As a result, this specification shifts responsibility for processing of Warning from intermediaries to the recipient that
    14591502         is actually consuming them.
    14601503      </p>
    1461       <p id="rfc.section.7.5.p.12">Generators of Warning header fields <em class="bcp14">MUST</em> include in every warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message. Recipients that process a Warning header field <em class="bcp14">MUST</em> ignore (and <em class="bcp14">MAY</em> remove before forwarding) a warning-value whose warn-date is different from the Date value in the response.
    1462       </p>
    1463       <p id="rfc.section.7.5.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
     1504      <p id="rfc.section.5.5.p.12">Generators of Warning header fields <em class="bcp14">MUST</em> include in every warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message. Recipients that process a Warning header field <em class="bcp14">MUST</em> ignore (and <em class="bcp14">MAY</em> remove before forwarding) a warning-value whose warn-date is different from the Date value in the response.
     1505      </p>
     1506      <p id="rfc.section.5.5.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
    14641507         of its meaning.
    14651508      </p>
    14661509      <div id="rfc.iref.50"></div>
    1467       <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a>&nbsp;<a id="warn.110" href="#warn.110">110 Response is Stale</a></h3>
    1468       <p id="rfc.section.7.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale.
     1510      <h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;<a id="warn.110" href="#warn.110">110 Response is Stale</a></h3>
     1511      <p id="rfc.section.5.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale.
    14691512      </p>
    14701513      <div id="rfc.iref.50"></div>
    1471       <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a>&nbsp;<a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3>
    1472       <p id="rfc.section.7.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach
     1514      <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3>
     1515      <p id="rfc.section.5.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach
    14731516         the server.
    14741517      </p>
    14751518      <div id="rfc.iref.50"></div>
    1476       <h3 id="rfc.section.7.5.3"><a href="#rfc.section.7.5.3">7.5.3</a>&nbsp;<a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3>
    1477       <p id="rfc.section.7.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time.
     1519      <h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;<a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3>
     1520      <p id="rfc.section.5.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time.
    14781521      </p>
    14791522      <div id="rfc.iref.50"></div>
    1480       <h3 id="rfc.section.7.5.4"><a href="#rfc.section.7.5.4">7.5.4</a>&nbsp;<a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3>
    1481       <p id="rfc.section.7.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than
     1523      <h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;<a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3>
     1524      <p id="rfc.section.5.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than
    14821525         24 hours.
    14831526      </p>
    14841527      <div id="rfc.iref.50"></div>
    1485       <h3 id="rfc.section.7.5.5"><a href="#rfc.section.7.5.5">7.5.5</a>&nbsp;<a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3>
    1486       <p id="rfc.section.7.5.5.p.1">The warning text can 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.
     1528      <h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;<a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3>
     1529      <p id="rfc.section.5.5.5.p.1">The warning text can 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.
    14871530      </p>
    14881531      <div id="rfc.iref.50"></div>
    1489       <h3 id="rfc.section.7.5.6"><a href="#rfc.section.7.5.6">7.5.6</a>&nbsp;<a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3>
    1490       <p id="rfc.section.7.5.6.p.1"><em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type,
     1532      <h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;<a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3>
     1533      <p id="rfc.section.5.5.6.p.1"><em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type,
    14911534         or modifying the representation data, unless this Warning code already appears in the response.
    14921535      </p>
    14931536      <div id="rfc.iref.50"></div>
    1494       <h3 id="rfc.section.7.5.7"><a href="#rfc.section.7.5.7">7.5.7</a>&nbsp;<a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3>
    1495       <p id="rfc.section.7.5.7.p.1">The warning text can 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.
    1496       </p>
    1497       <h3 id="rfc.section.7.5.8"><a href="#rfc.section.7.5.8">7.5.8</a>&nbsp;<a id="warn.code.extensions" href="#warn.code.extensions">Warn Code Extensions</a></h3>
    1498       <p id="rfc.section.7.5.8.p.1">Extension warn codes can be defined; see <a href="#warn.code.registry.procedure" title="Procedure">Section&nbsp;9.2.1</a> for details.
    1499       </p>
    1500       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
    1501       <p id="rfc.section.8.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation
     1537      <h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;<a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3>
     1538      <p id="rfc.section.5.5.7.p.1">The warning text can 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.
     1539      </p>
     1540      <h3 id="rfc.section.5.5.8"><a href="#rfc.section.5.5.8">5.5.8</a>&nbsp;<a id="warn.code.extensions" href="#warn.code.extensions">Warn Code Extensions</a></h3>
     1541      <p id="rfc.section.5.5.8.p.1">Extension warn codes can be defined; see <a href="#warn.code.registry.procedure" title="Procedure">Section&nbsp;7.2.1</a> for details.
     1542      </p>
     1543      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
     1544      <p id="rfc.section.6.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation
    15021545         retrieved earlier in a session.
    15031546      </p>
    1504       <p id="rfc.section.8.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if
     1547      <p id="rfc.section.6.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if
    15051548         it has expired.
    15061549      </p>
    1507       <p id="rfc.section.8.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives
     1550      <p id="rfc.section.6.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives
    15081551         (e.g., Cache-Control: no-store).
    15091552      </p>
    1510       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
    1511       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="cache.directive.registry" href="#cache.directive.registry">Cache Directive Registry</a></h2>
    1512       <p id="rfc.section.9.1.p.1">The HTTP Cache Directive Registry defines the name space for the cache directives. It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.
    1513       </p>
    1514       <h3 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a>&nbsp;<a id="cache.directive.registry.procedure" href="#cache.directive.registry.procedure">Procedure</a></h3>
    1515       <p id="rfc.section.9.1.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields:
     1553      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
     1554      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="cache.directive.registry" href="#cache.directive.registry">Cache Directive Registry</a></h2>
     1555      <p id="rfc.section.7.1.p.1">The HTTP Cache Directive Registry defines the name space for the cache directives. It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.
     1556      </p>
     1557      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="cache.directive.registry.procedure" href="#cache.directive.registry.procedure">Procedure</a></h3>
     1558      <p id="rfc.section.7.1.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields:
    15161559      </p>
    15171560      <ul>
    … …  
    15191562         <li>Pointer to specification text</li>
    15201563      </ul>
    1521       <p id="rfc.section.9.1.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
    1522       </p>
    1523       <h3 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a>&nbsp;<a id="cache.directive.considerations" href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3>
    1524       <p id="rfc.section.9.1.2.p.1">New extension directives ought to consider defining:</p>
    1525       <p id="rfc.section.9.1.2.p.2"></p>
     1564      <p id="rfc.section.7.1.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
     1565      </p>
     1566      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="cache.directive.considerations" href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3>
     1567      <p id="rfc.section.7.1.2.p.1">New extension directives ought to consider defining:</p>
     1568      <p id="rfc.section.7.1.2.p.2"></p>
    15261569      <ul>
    15271570         <li>What it means for a directive to be specified multiple times,</li>
    … …  
    15301573         <li>Whether the directive is specific to requests, responses, or able to be used in either.</li>
    15311574      </ul>
    1532       <p id="rfc.section.9.1.2.p.3">See also <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>.
    1533       </p>
    1534       <h3 id="rfc.section.9.1.3"><a href="#rfc.section.9.1.3">9.1.3</a>&nbsp;<a id="cache.directive.registration" href="#cache.directive.registration">Registrations</a></h3>
    1535       <p id="rfc.section.9.1.3.p.1">The HTTP Cache Directive Registry shall be populated with the registrations below:</p>
     1575      <p id="rfc.section.7.1.2.p.3">See also <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.
     1576      </p>
     1577      <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="cache.directive.registration" href="#cache.directive.registration">Registrations</a></h3>
     1578      <p id="rfc.section.7.1.3.p.1">The HTTP Cache Directive Registry shall be populated with the registrations below:</p>
    15361579      <div id="rfc.table.1">
    15371580         <div id="iana.cache.directive.registration.table"></div>
    … …  
    15461589               <tr>
    15471590                  <td class="left">max-age</td>
    1548                   <td class="left"><a href="#cache-request-directive.max-age" title="max-age">Section&nbsp;7.2.1.1</a>, <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>
     1591                  <td class="left"><a href="#cache-request-directive.max-age" title="max-age">Section&nbsp;5.2.1.1</a>, <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>
    15491592                  </td>
    15501593               </tr>
    15511594               <tr>
    15521595                  <td class="left">max-stale</td>
    1553                   <td class="left"><a href="#cache-request-directive.max-stale" title="max-stale">Section&nbsp;7.2.1.2</a>
     1596                  <td class="left"><a href="#cache-request-directive.max-stale" title="max-stale">Section&nbsp;5.2.1.2</a>
    15541597                  </td>
    15551598               </tr>
    15561599               <tr>
    15571600                  <td class="left">min-fresh</td>
    1558                   <td class="left"><a href="#cache-request-directive.min-fresh" title="min-fresh">Section&nbsp;7.2.1.3</a>
     1601                  <td class="left"><a href="#cache-request-directive.min-fresh" title="min-fresh">Section&nbsp;5.2.1.3</a>
    15591602                  </td>
    15601603               </tr>
    15611604               <tr>
    15621605                  <td class="left">must-revalidate</td>
    1563                   <td class="left"><a href="#cache-response-directive.must-revalidate" title="must-revalidate">Section&nbsp;7.2.2.1</a>
     1606                  <td class="left"><a href="#cache-response-directive.must-revalidate" title="must-revalidate">Section&nbsp;5.2.2.1</a>
    15641607                  </td>
    15651608               </tr>
    15661609               <tr>
    15671610                  <td class="left">no-cache</td>
    1568                   <td class="left"><a href="#cache-request-directive.no-cache" title="no-cache">Section&nbsp;7.2.1.4</a>, <a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;7.2.2.2</a>
     1611                  <td class="left"><a href="#cache-request-directive.no-cache" title="no-cache">Section&nbsp;5.2.1.4</a>, <a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>
    15691612                  </td>
    15701613               </tr>
    15711614               <tr>
    15721615                  <td class="left">no-store</td>
    1573                   <td class="left"><a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;7.2.1.5</a>, <a href="#cache-response-directive.no-store" title="no-store">Section&nbsp;7.2.2.3</a>
     1616                  <td class="left"><a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;5.2.1.5</a>, <a href="#cache-response-directive.no-store" title="no-store">Section&nbsp;5.2.2.3</a>
    15741617                  </td>
    15751618               </tr>
    15761619               <tr>
    15771620                  <td class="left">no-transform</td>
    1578                   <td class="left"><a href="#cache-request-directive.no-transform" title="no-transform">Section&nbsp;7.2.1.6</a>, <a href="#cache-response-directive.no-transform" title="no-transform">Section&nbsp;7.2.2.4</a>
     1621                  <td class="left"><a href="#cache-request-directive.no-transform" title="no-transform">Section&nbsp;5.2.1.6</a>, <a href="#cache-response-directive.no-transform" title="no-transform">Section&nbsp;5.2.2.4</a>
    15791622                  </td>
    15801623               </tr>
    15811624               <tr>
    15821625                  <td class="left">only-if-cached</td>
    1583                   <td class="left"><a href="#cache-request-directive.only-if-cached" title="only-if-cached">Section&nbsp;7.2.1.7</a>
     1626                  <td class="left"><a href="#cache-request-directive.only-if-cached" title="only-if-cached">Section&nbsp;5.2.1.7</a>
    15841627                  </td>
    15851628               </tr>
    15861629               <tr>
    15871630                  <td class="left">private</td>
    1588                   <td class="left"><a href="#cache-response-directive.private" title="private">Section&nbsp;7.2.2.6</a>
     1631                  <td class="left"><a href="#cache-response-directive.private" title="private">Section&nbsp;5.2.2.6</a>
    15891632                  </td>
    15901633               </tr>
    15911634               <tr>
    15921635                  <td class="left">proxy-revalidate</td>
    1593                   <td class="left"><a href="#cache-response-directive.proxy-revalidate" title="proxy-revalidate">Section&nbsp;7.2.2.7</a>
     1636                  <td class="left"><a href="#cache-response-directive.proxy-revalidate" title="proxy-revalidate">Section&nbsp;5.2.2.7</a>
    15941637                  </td>
    15951638               </tr>
    15961639               <tr>
    15971640                  <td class="left">public</td>
    1598                   <td class="left"><a href="#cache-response-directive.public" title="public">Section&nbsp;7.2.2.5</a>
     1641                  <td class="left"><a href="#cache-response-directive.public" title="public">Section&nbsp;5.2.2.5</a>
    15991642                  </td>
    16001643               </tr>
    16011644               <tr>
    16021645                  <td class="left">s-maxage</td>
    1603                   <td class="left"><a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.9</a>
     1646                  <td class="left"><a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a>
    16041647                  </td>
    16051648               </tr>
    … …  
    16171660         </table>
    16181661      </div>
    1619       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="warn.code.registry" href="#warn.code.registry">Warn Code Registry</a></h2>
    1620       <p id="rfc.section.9.2.p.1">The HTTP Warn Code Registry defines the name space for warn codes. It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>&gt;.
    1621       </p>
    1622       <h3 id="rfc.section.9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a>&nbsp;<a id="warn.code.registry.procedure" href="#warn.code.registry.procedure">Procedure</a></h3>
    1623       <p id="rfc.section.9.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields:
     1662      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="warn.code.registry" href="#warn.code.registry">Warn Code Registry</a></h2>
     1663      <p id="rfc.section.7.2.p.1">The HTTP Warn Code Registry defines the name space for warn codes. It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>&gt;.
     1664      </p>
     1665      <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="warn.code.registry.procedure" href="#warn.code.registry.procedure">Procedure</a></h3>
     1666      <p id="rfc.section.7.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields:
    16241667      </p>
    16251668      <ul>
    … …  
    16281671         <li>Pointer to specification text</li>
    16291672      </ul>
    1630       <p id="rfc.section.9.2.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
    1631       </p>
    1632       <h3 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a>&nbsp;<a id="warn.code.registration" href="#warn.code.registration">Registrations</a></h3>
    1633       <p id="rfc.section.9.2.2.p.1">The HTTP Warn Code Registry shall be populated with the registrations below:</p>
     1673      <p id="rfc.section.7.2.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
     1674      </p>
     1675      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="warn.code.registration" href="#warn.code.registration">Registrations</a></h3>
     1676      <p id="rfc.section.7.2.2.p.1">The HTTP Warn Code Registry shall be populated with the registrations below:</p>
    16341677      <div id="rfc.table.2">
    16351678         <div id="iana.warn.code.registration.table"></div>
    … …  
    16461689                  <td class="left">110</td>
    16471690                  <td class="left">Response is Stale</td>
    1648                   <td class="left"><a href="#warn.110" id="rfc.xref.warn.110.1" title="110 Response is Stale">Section&nbsp;7.5.1</a>
     1691                  <td class="left"><a href="#warn.110" id="rfc.xref.warn.110.1" title="110 Response is Stale">Section&nbsp;5.5.1</a>
    16491692                  </td>
    16501693               </tr>
    … …  
    16521695                  <td class="left">111</td>
    16531696                  <td class="left">Revalidation Failed</td>
    1654                   <td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="111 Revalidation Failed">Section&nbsp;7.5.2</a>
     1697                  <td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="111 Revalidation Failed">Section&nbsp;5.5.2</a>
    16551698                  </td>
    16561699               </tr>
    … …  
    16581701                  <td class="left">112</td>
    16591702                  <td class="left">Disconnected Operation</td>
    1660                   <td class="left"><a href="#warn.112" id="rfc.xref.warn.112.1" title="112 Disconnected Operation">Section&nbsp;7.5.3</a>
     1703                  <td class="left"><a href="#warn.112" id="rfc.xref.warn.112.1" title="112 Disconnected Operation">Section&nbsp;5.5.3</a>
    16611704                  </td>
    16621705               </tr>
    … …  
    16641707                  <td class="left">113</td>
    16651708                  <td class="left">Heuristic Expiration</td>
    1666                   <td class="left"><a href="#warn.113" id="rfc.xref.warn.113.1" title="113 Heuristic Expiration">Section&nbsp;7.5.4</a>
     1709                  <td class="left"><a href="#warn.113" id="rfc.xref.warn.113.1" title="113 Heuristic Expiration">Section&nbsp;5.5.4</a>
    16671710                  </td>
    16681711               </tr>
    … …  
    16701713                  <td class="left">199</td>
    16711714                  <td class="left">Miscellaneous Warning</td>
    1672                   <td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="199 Miscellaneous Warning">Section&nbsp;7.5.5</a>
     1715                  <td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="199 Miscellaneous Warning">Section&nbsp;5.5.5</a>
    16731716                  </td>
    16741717               </tr>
    … …  
    16761719                  <td class="left">214</td>
    16771720                  <td class="left">Transformation Applied</td>
    1678                   <td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="214 Transformation Applied">Section&nbsp;7.5.6</a>
     1721                  <td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="214 Transformation Applied">Section&nbsp;5.5.6</a>
    16791722                  </td>
    16801723               </tr>
    … …  
    16821725                  <td class="left">299</td>
    16831726                  <td class="left">Miscellaneous Persistent Warning</td>
    1684                   <td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="299 Miscellaneous Persistent Warning">Section&nbsp;7.5.7</a>
     1727                  <td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="299 Miscellaneous Persistent Warning">Section&nbsp;5.5.7</a>
    16851728                  </td>
    16861729               </tr>
    … …  
    16881731         </table>
    16891732      </div>
    1690       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1691       <p id="rfc.section.9.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained 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;.
    1692       </p>
    1693       <p id="rfc.section.9.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to
     1733      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     1734      <p id="rfc.section.7.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained 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;.
     1735      </p>
     1736      <p id="rfc.section.7.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to
    16941737         the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>):
    16951738      </p>
    … …  
    17101753                  <td class="left">http</td>
    17111754                  <td class="left">standard</td>
    1712                   <td class="left"><a href="#header.age" id="rfc.xref.header.age.3" title="Age">Section&nbsp;7.1</a>
     1755                  <td class="left"><a href="#header.age" id="rfc.xref.header.age.3" title="Age">Section&nbsp;5.1</a>
    17131756                  </td>
    17141757               </tr>
    … …  
    17171760                  <td class="left">http</td>
    17181761                  <td class="left">standard</td>
    1719                   <td class="left"><a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;7.2</a>
     1762                  <td class="left"><a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;5.2</a>
    17201763                  </td>
    17211764               </tr>
    … …  
    17241767                  <td class="left">http</td>
    17251768                  <td class="left">standard</td>
    1726                   <td class="left"><a href="#header.expires" id="rfc.xref.header.expires.4" title="Expires">Section&nbsp;7.3</a>
     1769                  <td class="left"><a href="#header.expires" id="rfc.xref.header.expires.4" title="Expires">Section&nbsp;5.3</a>
    17271770                  </td>
    17281771               </tr>
    … …  
    17311774                  <td class="left">http</td>
    17321775                  <td class="left">standard</td>
    1733                   <td class="left"><a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;7.4</a>
     1776                  <td class="left"><a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;5.4</a>
    17341777                  </td>
    17351778               </tr>
    … …  
    17381781                  <td class="left">http</td>
    17391782                  <td class="left">standard</td>
    1740                   <td class="left"><a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;7.5</a>
     1783                  <td class="left"><a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;5.5</a>
    17411784                  </td>
    17421785               </tr>
    … …  
    17441787         </table>
    17451788      </div>
    1746       <p id="rfc.section.9.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    1747       <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1748       <p id="rfc.section.10.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1
     1789      <p id="rfc.section.7.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     1790      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     1791      <p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1
    17491792         caching. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    17501793      </p>
    1751       <p id="rfc.section.10.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
     1794      <p id="rfc.section.8.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
    17521795         exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information
    17531796         long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected
    17541797         as sensitive information.
    17551798      </p>
    1756       <p id="rfc.section.10.p.3">Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first
     1799      <p id="rfc.section.8.p.3">Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first
    17571800         one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it
    17581801         load more quickly, thanks to the cache.
    17591802      </p>
    1760       <p id="rfc.section.10.p.4">Implementation flaws might allow attackers to insert content into a cache ("cache poisoning"), leading to compromise of clients
     1803      <p id="rfc.section.8.p.4">Implementation flaws might allow attackers to insert content into a cache ("cache poisoning"), leading to compromise of clients
    17611804         that trust that content. Because of their nature, these attacks are difficult to mitigate.
    17621805      </p>
    1763       <p id="rfc.section.10.p.5">Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information
     1806      <p id="rfc.section.8.p.5">Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information
    17641807         (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.
    17651808      </p>
    1766       <p id="rfc.section.10.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent
     1809      <p id="rfc.section.8.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent
    17671810         requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control
    17681811         response header fields.
    17691812      </p>
    1770       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1771       <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    1772       </p>
    1773       <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
     1813      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     1814      <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     1815      </p>
     1816      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    17741817      </h1>
    1775       <h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References
     1818      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    17761819      </h2>
    17771820      <table>
    … …  
    18121855         </tr>
    18131856      </table>
    1814       <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References
     1857      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    18151858      </h2>
    18161859      <table>
    … …  
    18731916         explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>)
    18741917      </p>
    1875       <p id="rfc.section.A.p.7">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;6</a>)
    1876       </p>
    1877       <p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;6</a>)
     1918      <p id="rfc.section.A.p.7">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>)
     1919      </p>
     1920      <p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>)
    18781921      </p>
    18791922      <p id="rfc.section.A.p.9">Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only
    1880          one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;7.2</a>)
     1923         one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;5.2</a>)
    18811924      </p>
    18821925      <p id="rfc.section.A.p.10">The "no-store" cache request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it,
    1883          and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;7.2.1.5</a>)
     1926         and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;5.2.1.5</a>)
    18841927      </p>
    18851928      <p id="rfc.section.A.p.11">The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; e.g., "private=foo"
    18861929         is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified.
    1887          (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>)
    1888       </p>
    1889       <p id="rfc.section.A.p.12">The "no-cache" response cache directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;7.2.2.2</a>)
    1890       </p>
    1891       <p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section&nbsp;7.3</a>)
    1892       </p>
    1893       <p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;7.4</a>)
     1930         (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>)
     1931      </p>
     1932      <p id="rfc.section.A.p.12">The "no-cache" response cache directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>)
     1933      </p>
     1934      <p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section&nbsp;5.3</a>)
     1935      </p>
     1936      <p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;5.4</a>)
    18941937      </p>
    18951938      <p id="rfc.section.A.p.15">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, presence of the warn-date component has been
    1896          made required (dropping requirements specific to HTTP/1.0). Finally, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;7.5</a>)
     1939         made required (dropping requirements specific to HTTP/1.0). Finally, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;5.5</a>)
    18971940      </p>
    18981941      <p id="rfc.section.A.p.16">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives.
    1899          (<a href="#cache.directive.registry" title="Cache Directive Registry">Section&nbsp;9.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section&nbsp;9.2</a>)
     1942         (<a href="#cache.directive.registry" title="Cache Directive Registry">Section&nbsp;7.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section&nbsp;7.2</a>)
    19001943      </p>
    19011944      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    … …  
    20322075         <ul class="ind">
    20332076            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    2034                   <li>110 Response is Stale (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.1</b></a>, <a href="#rfc.xref.warn.110.1">9.2.2</a></li>
    2035                   <li>111 Revalidation Failed (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.2</b></a>, <a href="#rfc.xref.warn.111.1">9.2.2</a></li>
    2036                   <li>112 Disconnected Operation (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.3</b></a>, <a href="#rfc.xref.warn.112.1">9.2.2</a></li>
    2037                   <li>113 Heuristic Expiration (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.4</b></a>, <a href="#rfc.xref.warn.113.1">9.2.2</a></li>
    2038                   <li>199 Miscellaneous Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.5</b></a>, <a href="#rfc.xref.warn.199.1">9.2.2</a></li>
     2077                  <li>110 Response is Stale (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.1">7.2.2</a></li>
     2078                  <li>111 Revalidation Failed (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li>
     2079                  <li>112 Disconnected Operation (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.1">7.2.2</a></li>
     2080                  <li>113 Heuristic Expiration (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.1">7.2.2</a></li>
     2081                  <li>199 Miscellaneous Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li>
    20392082               </ul>
    20402083            </li>
    20412084            <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
    2042                   <li>214 Transformation Applied (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.6</b></a>, <a href="#rfc.xref.warn.214.1">9.2.2</a></li>
    2043                   <li>299 Miscellaneous Persistent Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.7</b></a>, <a href="#rfc.xref.warn.299.1">9.2.2</a></li>
     2085                  <li>214 Transformation Applied (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li>
     2086                  <li>299 Miscellaneous Persistent Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li>
    20442087               </ul>
    20452088            </li>
    20462089            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    20472090                  <li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.2</a></li>
    2048                   <li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li>
     2091                  <li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>5.1</b></a>, <a href="#rfc.xref.header.age.3">7.3</a></li>
    20492092               </ul>
    20502093            </li>
    20512094            <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul>
    2052                   <li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">9.3</a>, <a href="#BCP90"><b>12.2</b></a></li>
     2095                  <li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">7.3</a>, <a href="#BCP90"><b>10.2</b></a></li>
    20532096               </ul>
    20542097            </li>
    … …  
    20572100                  <li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.2">2</a></li>
    20582101                  <li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li>
    2059                   <li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li>
     2102                  <li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>5.2</b></a>, <a href="#rfc.xref.header.cache-control.2">7.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li>
    20602103               </ul>
    20612104            </li>
    20622105            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    2063                   <li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>7.3</b></a>, <a href="#rfc.xref.header.expires.4">9.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li>
     2106                  <li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>5.3</b></a>, <a href="#rfc.xref.header.expires.4">7.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li>
    20642107                  <li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">4.2</a></li>
    20652108               </ul>
    … …  
    20742117                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    20752118                     <ul>
    2076                         <li><tt>Age</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>7.1</b></a></li>
    2077                         <li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>7.2</b></a></li>
    2078                         <li><tt>cache-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>7.2</b></a></li>
     2119                        <li><tt>Age</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>5.1</b></a></li>
     2120                        <li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>5.2</b></a></li>
     2121                        <li><tt>cache-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>5.2</b></a></li>
    20792122                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2.1</b></a></li>
    2080                         <li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>7.3</b></a></li>
    2081                         <li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>7.4</b></a></li>
    2082                         <li><tt>Pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>7.4</b></a></li>
    2083                         <li><tt>pragma-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>7.4</b></a></li>
    2084                         <li><tt>warn-agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>7.5</b></a></li>
    2085                         <li><tt>warn-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>7.5</b></a></li>
    2086                         <li><tt>warn-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>7.5</b></a></li>
    2087                         <li><tt>warn-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>7.5</b></a></li>
    2088                         <li><tt>Warning</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>7.5</b></a></li>
    2089                         <li><tt>warning-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>7.5</b></a></li>
     2123                        <li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>5.3</b></a></li>
     2124                        <li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>5.4</b></a></li>
     2125                        <li><tt>Pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>5.4</b></a></li>
     2126                        <li><tt>pragma-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>5.4</b></a></li>
     2127                        <li><tt>warn-agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>5.5</b></a></li>
     2128                        <li><tt>warn-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>5.5</b></a></li>
     2129                        <li><tt>warn-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>5.5</b></a></li>
     2130                        <li><tt>warn-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>5.5</b></a></li>
     2131                        <li><tt>Warning</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>5.5</b></a></li>
     2132                        <li><tt>warning-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>5.5</b></a></li>
    20902133                     </ul>
    20912134                  </li>
    … …  
    20972140            </li>
    20982141            <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul>
    2099                   <li>max-age (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>7.2.1.1</b></a>, <a href="#rfc.iref.m.5"><b>7.2.2.8</b></a></li>
    2100                   <li>max-stale (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>7.2.1.2</b></a></li>
    2101                   <li>min-fresh (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>7.2.1.3</b></a></li>
    2102                   <li>must-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>7.2.2.1</b></a></li>
     2142                  <li>max-age (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>5.2.1.1</b></a>, <a href="#rfc.iref.m.5"><b>5.2.2.8</b></a></li>
     2143                  <li>max-stale (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>5.2.1.2</b></a></li>
     2144                  <li>min-fresh (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>5.2.1.3</b></a></li>
     2145                  <li>must-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>5.2.2.1</b></a></li>
    21032146               </ul>
    21042147            </li>
    21052148            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    2106                   <li>no-cache (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>7.2.1.4</b></a>, <a href="#rfc.iref.n.4"><b>7.2.2.2</b></a></li>
    2107                   <li>no-store (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.2"><b>7.2.1.5</b></a>, <a href="#rfc.iref.n.5"><b>7.2.2.3</b></a></li>
    2108                   <li>no-transform (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.3"><b>7.2.1.6</b></a>, <a href="#rfc.iref.n.6"><b>7.2.2.4</b></a></li>
     2149                  <li>no-cache (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>5.2.1.4</b></a>, <a href="#rfc.iref.n.4"><b>5.2.2.2</b></a></li>
     2150                  <li>no-store (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.2"><b>5.2.1.5</b></a>, <a href="#rfc.iref.n.5"><b>5.2.2.3</b></a></li>
     2151                  <li>no-transform (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.3"><b>5.2.1.6</b></a>, <a href="#rfc.iref.n.6"><b>5.2.2.4</b></a></li>
    21092152               </ul>
    21102153            </li>
    21112154            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    2112                   <li>only-if-cached (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>7.2.1.7</b></a></li>
     2155                  <li>only-if-cached (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>5.2.1.7</b></a></li>
    21132156               </ul>
    21142157            </li>
    21152158            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2116                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>
     2159                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.6">4.4</a>, <a href="#rfc.xref.Part1.7">4.4</a>, <a href="#rfc.xref.Part1.8">4.4</a>, <a href="#rfc.xref.Part1.9">5.2.1.6</a>, <a href="#rfc.xref.Part1.10">5.2.2.4</a>, <a href="#rfc.xref.Part1.11">8</a>, <a href="#rfc.xref.Part1.12">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>
    21172160                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">C</a></li>
    21182161                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    … …  
    21212164                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">B</a></li>
    21222165                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a></li>
    2123                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a></li>
     2166                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.6">4.4</a>, <a href="#rfc.xref.Part1.7">4.4</a>, <a href="#rfc.xref.Part1.8">4.4</a></li>
    21242167                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">B</a></li>
    2125                         <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a></li>
     2168                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">5.2.1.6</a>, <a href="#rfc.xref.Part1.10">5.2.2.4</a></li>
    21262169                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    2127                         <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">11</a></li>
     2170                        <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">9</a></li>
    21282171                     </ul>
    21292172                  </li>
    2130                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>
    2131                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">6</a></li>
     2173                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6">4.4</a>, <a href="#rfc.xref.Part2.7">5.3</a>, <a href="#rfc.xref.Part2.8">8</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>
     2174                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">4.4</a></li>
    21322175                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2</a></li>
    2133                         <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.9">B</a></li>
     2176                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">5.3</a>, <a href="#rfc.xref.Part2.9">B</a></li>
    21342177                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.2.3</a></li>
    21352178                        <li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
    21362179                     </ul>
    21372180                  </li>
    2138                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#Part4"><b>12.1</b></a><ul>
    2139                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">4.3.1</a></li>
    2140                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a></li>
     2181                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">4.3.1</a>, <a href="#rfc.xref.Part4.5">4.3.2</a>, <a href="#rfc.xref.Part4.6">4.3.2</a>, <a href="#rfc.xref.Part4.7">4.3.2</a>, <a href="#rfc.xref.Part4.8">4.3.2</a>, <a href="#rfc.xref.Part4.9">4.3.2</a>, <a href="#rfc.xref.Part4.10">4.3.4</a>, <a href="#Part4"><b>10.1</b></a><ul>
     2182                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">4.3.4</a></li>
     2183                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.3">4.3.1</a></li>
     2184                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">4.3.1</a></li>
     2185                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">4.3.2</a></li>
     2186                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">4.3.2</a></li>
     2187                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">4.3.2</a></li>
     2188                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">4.3.2</a></li>
     2189                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">4.3.2</a></li>
    21412190                     </ul>
    21422191                  </li>
    2143                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#Part5"><b>12.1</b></a><ul>
     2192                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.3.2</a>, <a href="#rfc.xref.Part5.5">4.3.2</a>, <a href="#Part5"><b>10.1</b></a><ul>
     2193                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.5">4.3.2</a></li>
    21442194                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">3.3</a></li>
    21452195                     </ul>
    21462196                  </li>
    2147                   <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#Part7"><b>12.1</b></a><ul>
     2197                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#Part7"><b>10.1</b></a><ul>
    21482198                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3</a>, <a href="#rfc.xref.Part7.2">3.2</a></li>
    21492199                     </ul>
    21502200                  </li>
    2151                   <li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>7.4</b></a>, <a href="#rfc.xref.header.pragma.2">9.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li>
    2152                   <li>private (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>7.2.2.6</b></a></li>
     2201                  <li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>5.4</b></a>, <a href="#rfc.xref.header.pragma.2">7.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li>
     2202                  <li>private (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>5.2.2.6</b></a></li>
    21532203                  <li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1</a></li>
    2154                   <li>proxy-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>7.2.2.7</b></a></li>
    2155                   <li>public (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>7.2.2.5</b></a></li>
     2204                  <li>proxy-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>5.2.2.7</b></a></li>
     2205                  <li>public (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>5.2.2.5</b></a></li>
    21562206               </ul>
    21572207            </li>
    21582208            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    2159                   <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.2.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
    2160                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    2161                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul>
     2209                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.2.3</a>, <a href="#RFC1305"><b>10.2</b></a></li>
     2210                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
     2211                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>10.2</b></a><ul>
    21622212                        <li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a></li>
    21632213                     </ul>
    21642214                  </li>
    2165                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">9.1.1</a>, <a href="#rfc.xref.RFC5226.2">9.2.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
    2166                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">9.1.1</a>, <a href="#rfc.xref.RFC5226.2">9.2.1</a></li>
     2215                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
     2216                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a></li>
    21672217                     </ul>
    21682218                  </li>
    2169                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>12.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>
     2219                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>
    21702220                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li>
    21712221                     </ul>
    21722222                  </li>
    2173                   <li><em>RFC5861</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">9.1.3</a>, <a href="#rfc.xref.RFC5861.2">9.1.3</a>, <a href="#RFC5861"><b>12.2</b></a><ul>
    2174                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.2">9.1.3</a></li>
    2175                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">9.1.3</a></li>
     2223                  <li><em>RFC5861</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">7.1.3</a>, <a href="#rfc.xref.RFC5861.2">7.1.3</a>, <a href="#RFC5861"><b>10.2</b></a><ul>
     2224                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.2">7.1.3</a></li>
     2225                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">7.1.3</a></li>
    21762226                     </ul>
    21772227                  </li>
    2178                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">10</a>, <a href="#RFC6265"><b>12.2</b></a></li>
     2228                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">8</a>, <a href="#RFC6265"><b>10.2</b></a></li>
    21792229               </ul>
    21802230            </li>
    21812231            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    2182                   <li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>7.2.2.9</b></a></li>
     2232                  <li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>5.2.2.9</b></a></li>
    21832233                  <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1</a></li>
    21842234                  <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">4.2</a></li>
    2185                   <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.3.1</a></li>
     2235                  <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.3.4</a></li>
    21862236               </ul>
    21872237            </li>
    21882238            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    2189                   <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.3</a></li>
     2239                  <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.3.1</a></li>
    21902240               </ul>
    21912241            </li>
    21922242            <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul>
    2193                   <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>
     2243                  <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3.4</a>, <a href="#rfc.xref.header.warning.4">4.3.5</a>, <a href="#rfc.iref.w.1"><b>5.5</b></a>, <a href="#rfc.xref.header.warning.5">7.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>
    21942244               </ul>
    21952245            </li>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r2371 r2372  
    2929  <!ENTITY semantics                   "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY conditional-precedence      "<xref target='Part4' x:rel='#precedence' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3132  <!ENTITY partial                     "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3233  <!ENTITY combining-byte-ranges       "<xref target='Part5' x:rel='#combining.byte.ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    3536  <!ENTITY header-connection           "<xref target='Part1' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3637  <!ENTITY header-date                 "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     38  <!ENTITY header-etag                 "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     39  <!ENTITY header-if-match             "<xref target='Part4' x:rel='#header.if-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     40  <!ENTITY header-if-none-match        "<xref target='Part4' x:rel='#header.if-none-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     41  <!ENTITY header-if-modified-since    "<xref target='Part4' x:rel='#header.if-modified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     42  <!ENTITY header-if-unmodified-since  "<xref target='Part4' x:rel='#header.if-unmodified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     43  <!ENTITY header-if-range             "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3744  <!ENTITY header-last-modified        "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3845  <!ENTITY header-vary                 "<xref target='Part2' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    439446<t>
    440447   Also, note that unsafe requests might invalidate already stored responses;
    441    see <xref target="invalidation.after.updates.or.deletions" />.
     448   see <xref target="invalidation" />.
    442449</t>
    443450<t>
    … …  
    833840   be selected; see <xref target="caching.negotiated.responses"/>), it can use
    834841   the conditional request mechanism &conditional; in the forwarded request to
    835    give the origin server an opportunity to both select a valid stored
    836    response to be used, and to update it. This process is known as
     842   give the next inbound server an opportunity to select a valid stored
     843   response to use, updating the stored metadata in the process, or to replace
     844   the stored response(s) with a new response. This process is known as
    837845   "validating" or "revalidating" the stored response.
    838846</t>
    839 <iref item="validator" />
    840 <t>
    841    When sending such a conditional request, a cache adds a
    842    <x:dfn>validator</x:dfn> (or more than one), that is used to find
    843    out whether a stored response is an equivalent copy of a current
     847
     848<section anchor="validation.sent" title="Sending a Validation Request"><iref item="validator" />
     849<t>
     850   When sending a conditional request for cache validation, a cache sends one
     851   or more precondition header fields containing <x:dfn>validator</x:dfn>
     852   metadata from its stored response(s), which is then compared by recipients
     853   to determine whether a stored response is equivalent to a current
    844854   representation of the resource.
    845855</t>
    846856<t>
    847    One such validator is the <x:ref>If-Modified-Since</x:ref> header field,
    848    whose value is that of the <x:ref>Last-Modified</x:ref> header field from
    849    the selected (see <xref target="caching.negotiated.responses"/>) stored
    850    response, if available.
    851 </t>
    852 <t>
    853    Another is the <x:ref>If-None-Match</x:ref> header field,
    854    whose value is that of the <x:ref>ETag</x:ref> header field(s) from
    855    relevant responses stored for the primary cache key, if present. However,
    856    if any of the stored responses contains only partial content, the cache
    857    ought not include its entity-tag in the If-None-Match header field unless
    858    the request is for a range that would be fully satisfied by that stored
    859    response.
    860 </t>
    861 
    862 <t>Cache handling of a response to a conditional request is dependent upon its
    863 status code:</t>
    864 
     857   One such validator is the timestamp given in a <x:ref>Last-Modified</x:ref>
     858   header field (&header-last-modified;), which can be used in an
     859   <x:ref>If-Modified-Since</x:ref> header field for response validation, or
     860   in an <x:ref>If-Unmodified-Since</x:ref> or <x:ref>If-Range</x:ref> header
     861   field for representation selection (i.e., the client is referring
     862   specifically to a previously obtained representation with that timestamp).
     863</t>
     864<t>
     865   Another validator is the entity-tag given in an <x:ref>ETag</x:ref> header
     866   field (&header-etag;). One or more entity-tags, indicating one or more
     867   stored responses, can be used in an <x:ref>If-None-Match</x:ref> header
     868   field for response validation, or in an <x:ref>If-Match</x:ref> or
     869   <x:ref>If-Range</x:ref> header field for representation selection (i.e.,
     870   the client is referring specifically to one or more previously obtained
     871   representations with the listed entity-tags).
     872</t>
     873</section>
     874
     875<section anchor="validation.received" title="Handling a Received Validation Request">
     876<t>
     877   Each client in the request chain may have its own cache, so it is common
     878   for a cache at an intermediary or origin server to receive conditional
     879   requests from other (outbound) caches. Likewise, some user agents make use
     880   of conditional requests to limit data transfers to recently modified
     881   representations or to complete the transfer of partially retrieved
     882   representations.
     883</t>
     884<t>
     885   If the request semantics can be satisfied with a cached response and a
     886   recipient cache has at least one response stored for this primary cache
     887   key, the cache &MUST; evaluate received precondition header fields as part
     888   of its selection process for determining a suitable response.
     889   A cache &MUST-NOT; evaluate received precondition header fields in a
     890   request with semantics that cannot be satisfied with a cached response, or
     891   for which the cache has no prior stored responses, since such preconditions
     892   are intended for some other (inbound) server.
     893</t>
     894<t>
     895   The proper evaluation of conditional requests by a cache depends on the
     896   received precondition header fields and their precedence, as defined in
     897   &conditional-precedence;.
     898</t>
     899<t>
     900   A request containing an <x:ref>If-Match</x:ref> header field
     901   (&header-if-match;) indicates that the client wants to receive an error
     902   response if the cache has a stored response that cannot be used to answer
     903   this request.
     904   The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref>
     905   response if the field-value is "*" and no suitable response is stored, or
     906   if the field-value is a list of entity-tags and none of them match the
     907   entity-tag of a suitable stored response.
     908   Otherwise, the cache &MUST; generate a <x:ref>2xx (Successful)</x:ref>
     909   response that reuses the most recent of its matching stored responses to
     910   satisfy the request.
     911</t>
     912<t>
     913   A request containing an <x:ref>If-Unmodified-Since</x:ref> header field
     914   (&header-if-unmodified-since;) indicates that the client wants to receive
     915   an error response if the cache has a stored response that cannot be used
     916   to answer this request.
     917   The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref>
     918   response if one of the following is true:
     919   1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that
     920   is more recent than the conditional timestamp;
     921   2) no <x:ref>Last-Modified</x:ref> field is present, but a stored
     922   response has a <x:ref>Date</x:ref> field-value that is more recent than the
     923   conditional timestamp; or,
     924   3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present,
     925   but the cache recorded a stored response as having been received at a
     926   time more recent than the conditional timestamp.
     927   Otherwise, the cache &MUST; generate a <x:ref>2xx (Successful)</x:ref>
     928   response that reuses the most recent of its matching stored responses to
     929   satisfy the request.
     930</t>
     931<t>
     932   A request containing an <x:ref>If-None-Match</x:ref> header field
     933   (&header-if-none-match;) indicates that the client wants to validate one
     934   or more of its stored responses.
     935   If the field-value is "*" and any suitable response is
     936   stored, or the field-value is a list of entity-tags and at least one of
     937   them match the entity-tag of a suitable stored response, the cache &MUST;
     938   generate a <x:ref>304 (Not Modified)</x:ref> response using the most
     939   suitable of those matching responses as the selected representation.
     940   Otherwise, if the cache has one or more suitable stored responses that
     941   do not match the condition, the cache &MUST; generate a
     942   <x:ref>2xx (Successful)</x:ref> response that reuses the most suitable of
     943   those stored responses to satisfy the request.
     944   Finally, if the cache has no suitable stored responses, the cache &SHOULD;
     945   forward the conditional request toward the origin server; if the received
     946   condition contains a list of entity-tags and the cache has its own set of
     947   stored responses for that primary cache key, the cache &SHOULD; take the
     948   union of the received set with the set of entity-tags for its own stored
     949   set of responses (fresh or stale) and generate an
     950   <x:ref>If-None-Match</x:ref> header field containing that union when it
     951   forwards the request toward the origin server.
     952   However, if a stored responses contains only partial content, the cache
     953   &MUST-NOT; include its entity-tag in the union unless the request is for
     954   a range that would be fully satisfied by that stored response.
     955</t>
     956<t>
     957   A request containing an <x:ref>If-Modified-Since</x:ref> header field
     958   (&header-if-modified-since;) indicates that the client wants to validate
     959   one or more of its stored responses by modification date if the stored
     960   responses have no entity-tag or the recipient does not implement
     961   <x:ref>If-None-Match</x:ref>.
     962   The cache &MUST; generate a <x:ref>2xx (Successful)</x:ref> response,
     963   reusing the most recent of its stored responses to satisfy the request,
     964   if one of the following is true:
     965   1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that
     966   is more recent than the conditional timestamp;
     967   2) no <x:ref>Last-Modified</x:ref> field is present, but a stored
     968   response has a <x:ref>Date</x:ref> field-value that is more recent than the
     969   conditional timestamp; or,
     970   3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present,
     971   but the cache recorded a stored response as having been received at a
     972   time more recent than the conditional timestamp.
     973   Otherwise, if the cache has one or more suitable stored responses, the
     974   cache &MUST; generate a <x:ref>304 (Not Modified)</x:ref> response using
     975   the most recent of its suitable stored responses as the selected
     976   representation.
     977   Finally, if the cache has no suitable stored responses, the cache &SHOULD;
     978   forward the conditional request toward the origin server.
     979</t>
     980<t>
     981   A cache that implements partial responses to range requests, as defined in
     982   &partial;, also needs to evaluate a received <x:ref>If-Range</x:ref> header
     983   field (&header-if-range;) in respect to its selected stored response.
     984</t>
     985</section>
     986
     987<section anchor="validation.response" title="Handling a Validation Response">
     988<t>
     989   Cache handling of a response to a conditional request is dependent upon its
     990   status code:
     991</t>
    865992<t>
    866993   <list style="symbols">
    … …  
    8731000         A full response (i.e., one with a payload body) indicates that none
    8741001         of the stored responses nominated in the conditional request is
    875          suitable. Instead, the cache can use the full response to
     1002         suitable. Instead, the cache &MUST; use the full response to
    8761003         satisfy the request and &MAY; replace the stored response(s).
    8771004      </t>
    … …  
    8801007         response while attempting to validate a response, it can either
    8811008         forward this response to the requesting client, or act as if the
    882          server failed to respond. In the latter case, it can send a
     1009         server failed to respond. In the latter case, the cache &MAY; send a
    8831010         previously stored response (see <xref
    8841011         target="serving.stale.responses" />).
    … …  
    8861013   </list>
    8871014</t>
     1015</section>
    8881016
    8891017<section anchor="freshening.responses" title="Freshening Stored Responses upon Validation">
    … …  
    9361064</section>
    9371065
    938 </section>
    939 
    940 </section>
    941 
    942 
    943 <section anchor="head.effects" title="Updating Caches with HEAD Responses">
     1066<section anchor="head.effects" title="Freshening Responses via HEAD">
    9441067<t>
    9451068   A response to the HEAD method is identical to what an equivalent request
    9461069   made with a GET would have been, except it lacks a body. This property
    947    of HEAD responses is used to both invalidate and update cached GET
    948    responses.
     1070   of HEAD responses can be used to invalidate or update a cached GET
     1071   response if the more efficient conditional GET request mechanism is not
     1072   available (due to no validators being present in the stored response) or
     1073   if transmission of the representation body is not desired even if it has
     1074   changed.
    9491075</t>
    9501076<t>
    … …  
    9681094      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
    9691095         with warn-code 2xx; and,</t>
    970       <t>use other header fields provided in the response to replace
     1096      <t>use other header fields provided in the HEAD response to replace
    9711097         all instances of the corresponding header fields in the stored
    9721098         response.</t>
    9731099   </list>
    9741100</t>
    975 
    976 </section>
    977 
    978 
    979 <section anchor="invalidation.after.updates.or.deletions"
    980    title="Request Methods that Invalidate">
     1101</section>
     1102</section>
     1103
     1104
     1105<section anchor="invalidation" title="Invalidation">
    9811106<t>
    9821107   Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE
    … …  
    10151140   might be stored in other caches that it has not.</t>
    10161141</section>
    1017 
     1142</section>
    10181143
    10191144
    … …  
    21572282      <x:defines>304</x:defines>
    21582283      <x:defines>304 (Not Modified)</x:defines>
     2284      <x:defines>412 (Precondition Failed)</x:defines>
    21592285      <x:defines>ETag</x:defines>
    21602286      <x:defines>If-Modified-Since</x:defines>
     2287      <x:defines>If-Unmodified-Since</x:defines>
     2288      <x:defines>If-Match</x:defines>
    21612289      <x:defines>If-None-Match</x:defines>
    21622290      <x:defines>Last-Modified</x:defines>
    … …  
    21852313      <x:defines>206 (Partial Content)</x:defines>
    21862314      <x:defines>Content-Range</x:defines>
     2315      <x:defines>If-Range</x:defines>
    21872316      <x:defines>Range</x:defines>
    21882317    </x:source>
    … …  
    23962525  Requirements regarding denial of service attack avoidance when performing
    23972526  invalidation have been clarified.
    2398   (<xref target="invalidation.after.updates.or.deletions" />)
     2527  (<xref target="invalidation" />)
    23992528</t>
    24002529<t>
    24012530  Cache invalidation only occurs when a successful response is received.
    2402   (<xref target="invalidation.after.updates.or.deletions" />)
     2531  (<xref target="invalidation" />)
    24032532</t>
    24042533<t>
Note: See TracChangeset for help on using the changeset viewer.