Changeset 157 for draft-ietf-httpbis
- Timestamp:
- 08/01/08 03:19:58 (15 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r155 r157 768 768 <dl class="empty"> 769 769 <dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 770 The rules for determining the cacheability of HTTP responses are defined in <a href="p6-cache.html#caching" title=" Caching in HTTP">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular770 The rules for determining the cacheability of HTTP responses are defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular 771 771 request. 772 772 </dd> … … 825 825 <--------- response chain 826 826 </pre><p id="rfc.section.1.4.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache 827 behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title=" Caching in HTTP">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.827 behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 828 828 </p> 829 829 <p id="rfc.section.1.4.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with … … 1288 1288 to the entity being transferred. These header fields apply only to the message being transmitted. 1289 1289 </p> 1290 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.60"></span> general-header = Cache-Control ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>1290 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.60"></span> general-header = Cache-Control ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 15.2</a> 1291 1291 | Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1292 1292 | Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> 1293 | Pragma ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>1293 | Pragma ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 15.4</a> 1294 1294 | Trailer ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.6</a> 1295 1295 | Transfer-Encoding ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.7</a> 1296 1296 | Upgrade ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.8</a> 1297 1297 | Via ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.9</a> 1298 | Warning ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>1298 | Warning ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 15.6</a> 1299 1299 </pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new 1300 1300 or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize … … 2649 2649 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">D.3</a></li> 2650 2650 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a>, <a class="iref" href="#rfc.xref.Part6.3">4.5</a>, <a class="iref" href="#rfc.xref.Part6.4">4.5</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.6">D.3</a><ul class="ind"> 2651 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a></li>2652 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part6.3">4.5</a></li>2653 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part6.4">4.5</a></li>2654 <li class="indline1"><em>Section 3.6</em> <a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>2651 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a></li> 2652 <li class="indline1"><em>Section 15.2</em> <a class="iref" href="#rfc.xref.Part6.3">4.5</a></li> 2653 <li class="indline1"><em>Section 15.4</em> <a class="iref" href="#rfc.xref.Part6.4">4.5</a></li> 2654 <li class="indline1"><em>Section 15.6</em> <a class="iref" href="#rfc.xref.Part6.5">4.5</a></li> 2655 2655 </ul> 2656 2656 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r153 r157 745 745 </p> 746 746 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> response-header = Accept-Ranges ; <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> 747 | Age ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 3.1</a>747 | Age ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 15.1</a> 748 748 | ETag ; <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> 749 749 | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a> … … 751 751 | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.7</a> 752 752 | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.8</a> 753 | Vary ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a>753 | Vary ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> 754 754 | WWW-Authenticate ; <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a> 755 755 </pre><p id="rfc.section.6.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new … … 1928 1928 </li> 1929 1929 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">6</a>, <a class="iref" href="#rfc.xref.Part6.2">6</a>, <a class="iref" href="#rfc.xref.Part6.3">8.3</a>, <a class="iref" href="#Part6"><b>14.1</b></a><ul class="ind"> 1930 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part6.1">6</a></li>1931 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.2">6</a></li>1930 <li class="indline1"><em>Section 15.1</em> <a class="iref" href="#rfc.xref.Part6.1">6</a></li> 1931 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6.2">6</a></li> 1932 1932 </ul> 1933 1933 </li> -
draft-ietf-httpbis/latest/p3-payload.html
r153 r157 759 759 | Content-Range ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> 760 760 | Content-Type ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 5.9</a> 761 | Expires ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a>761 | Expires ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 15.3</a> 762 762 | Last-Modified ; <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> 763 763 | extension-header … … 835 835 header fields not defined by this specification. 836 836 </p> 837 <p id="rfc.section.4.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.837 <p id="rfc.section.4.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 838 838 </p> 839 839 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> … … 1114 1114 <p id="rfc.section.5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond 1115 1115 to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple 1116 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1116 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 7</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1117 1117 </p> 1118 1118 <p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p> … … 1662 1662 </li> 1663 1663 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.7</a>, <a class="iref" href="#Part6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part6.4">C.1</a><ul class="ind"> 1664 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part6.3">5.7</a></li>1665 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a></li>1666 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li>1664 <li class="indline1"><em>Section 7</em> <a class="iref" href="#rfc.xref.Part6.3">5.7</a></li> 1665 <li class="indline1"><em>Section 15.3</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a></li> 1666 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li> 1667 1667 </ul> 1668 1668 </li> -
draft-ietf-httpbis/latest/p4-conditional.html
r153 r157 756 756 header <em class="bcp14">MUST</em> be ignored. 757 757 </p> 758 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.758 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 759 759 </p> 760 760 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. … … 837 837 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 838 838 </p> 839 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.839 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. 840 840 </p> 841 841 <p id="rfc.section.6.4.p.9">Examples:</p> … … 1065 1065 </li> 1066 1066 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind"> 1067 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li>1067 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6.1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li> 1068 1068 </ul> 1069 1069 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r154 r157 333 333 <link rel="Index" href="#rfc.index"> 334 334 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 335 <link rel="Chapter" title="2 Caching in HTTP" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Header Field Definitions" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 IANA Considerations" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Security Considerations" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 Acknowledgments" href="#rfc.section.6"> 340 <link rel="Chapter" href="#rfc.section.7" title="7 References"> 335 <link rel="Chapter" title="2 Overview" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Expiration Model" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 Validation Model" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Response Cacheability" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 Constructing Responses From Caches" href="#rfc.section.6"> 340 <link rel="Chapter" title="7 Caching Negotiated Responses" href="#rfc.section.7"> 341 <link rel="Chapter" title="8 Shared and Non-Shared Caches" href="#rfc.section.8"> 342 <link rel="Chapter" title="9 Errors or Incomplete Response Cache Behavior" href="#rfc.section.9"> 343 <link rel="Chapter" title="10 Side Effects of GET and HEAD" href="#rfc.section.10"> 344 <link rel="Chapter" title="11 Invalidation After Updates or Deletions" href="#rfc.section.11"> 345 <link rel="Chapter" title="12 Write-Through Mandatory" href="#rfc.section.12"> 346 <link rel="Chapter" title="13 Cache Replacement" href="#rfc.section.13"> 347 <link rel="Chapter" title="14 History Lists" href="#rfc.section.14"> 348 <link rel="Chapter" title="15 Header Field Definitions" href="#rfc.section.15"> 349 <link rel="Chapter" title="16 IANA Considerations" href="#rfc.section.16"> 350 <link rel="Chapter" title="17 Security Considerations" href="#rfc.section.17"> 351 <link rel="Chapter" title="18 Acknowledgments" href="#rfc.section.18"> 352 <link rel="Chapter" href="#rfc.section.19" title="19 References"> 341 353 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 342 354 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> … … 476 488 <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> 477 489 <ul class="toc"> 478 <li class="tocline0">1. <a href="# introduction">Introduction</a><ul class="toc">479 <li class="tocline1">1.1 <a href="#intro. requirements">Requirements</a></li>490 <li class="tocline0">1. <a href="#caching">Introduction</a><ul class="toc"> 491 <li class="tocline1">1.1 <a href="#intro.purpose">Purpose</a></li> 480 492 <li class="tocline1">1.2 <a href="#intro.terminology">Terminology</a></li> 481 <li class="tocline1">1.3 <a href="# delta.seconds">Delta Seconds</a></li>493 <li class="tocline1">1.3 <a href="#intro.requirements">Requirements</a></li> 482 494 </ul> 483 495 </li> 484 <li class="tocline0">2. <a href="#caching">Caching in HTTP</a><ul class="toc"> 485 <li class="tocline1">2.1 <a href="#caching.overview">Overview</a><ul class="toc"> 486 <li class="tocline1">2.1.1 <a href="#cache.correctness">Cache Correctness</a></li> 487 <li class="tocline1">2.1.2 <a href="#warnings">Warnings</a></li> 488 <li class="tocline1">2.1.3 <a href="#cache-control.mechanisms">Cache-control Mechanisms</a></li> 489 <li class="tocline1">2.1.4 <a href="#explicit.ua.warnings">Explicit User Agent Warnings</a></li> 490 <li class="tocline1">2.1.5 <a href="#exceptions.to.the.rules.and.warnings">Exceptions to the Rules and Warnings</a></li> 491 <li class="tocline1">2.1.6 <a href="#client-controlled.behavior">Client-controlled Behavior</a></li> 496 <li class="tocline0">2. <a href="#caching.overview">Overview</a><ul class="toc"> 497 <li class="tocline1">2.1 <a href="#cache.correctness">Cache Correctness</a></li> 498 <li class="tocline1">2.2 <a href="#warnings">Warnings</a></li> 499 <li class="tocline1">2.3 <a href="#cache-control.mechanisms">Cache-control Mechanisms</a></li> 500 <li class="tocline1">2.4 <a href="#explicit.ua.warnings">Explicit User Agent Warnings</a></li> 501 <li class="tocline1">2.5 <a href="#exceptions.to.the.rules.and.warnings">Exceptions to the Rules and Warnings</a></li> 502 <li class="tocline1">2.6 <a href="#client-controlled.behavior">Client-controlled Behavior</a></li> 503 </ul> 504 </li> 505 <li class="tocline0">3. <a href="#expiration.model">Expiration Model</a><ul class="toc"> 506 <li class="tocline1">3.1 <a href="#server-specified.expiration">Server-Specified Expiration</a></li> 507 <li class="tocline1">3.2 <a href="#heuristic.expiration">Heuristic Expiration</a></li> 508 <li class="tocline1">3.3 <a href="#age.calculations">Age Calculations</a></li> 509 <li class="tocline1">3.4 <a href="#expiration.calculations">Expiration Calculations</a></li> 510 <li class="tocline1">3.5 <a href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></li> 511 <li class="tocline1">3.6 <a href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></li> 512 </ul> 513 </li> 514 <li class="tocline0">4. <a href="#validation.model">Validation Model</a><ul class="toc"> 515 <li class="tocline1">4.1 <a href="#last-modified.dates">Last-Modified Dates</a></li> 516 <li class="tocline1">4.2 <a href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></li> 517 <li class="tocline1">4.3 <a href="#non-validating.conditionals">Non-validating Conditionals</a></li> 518 </ul> 519 </li> 520 <li class="tocline0">5. <a href="#response.cacheability">Response Cacheability</a></li> 521 <li class="tocline0">6. <a href="#constructing.responses.from.caches">Constructing Responses From Caches</a><ul class="toc"> 522 <li class="tocline1">6.1 <a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li> 523 <li class="tocline1">6.2 <a href="#non-modifiable.headers">Non-modifiable Headers</a></li> 524 <li class="tocline1">6.3 <a href="#combining.headers">Combining Headers</a></li> 525 </ul> 526 </li> 527 <li class="tocline0">7. <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 528 <li class="tocline0">8. <a href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></li> 529 <li class="tocline0">9. <a href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></li> 530 <li class="tocline0">10. <a href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></li> 531 <li class="tocline0">11. <a href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></li> 532 <li class="tocline0">12. <a href="#write-through.mandatory">Write-Through Mandatory</a></li> 533 <li class="tocline0">13. <a href="#cache.replacement">Cache Replacement</a></li> 534 <li class="tocline0">14. <a href="#history.lists">History Lists</a></li> 535 <li class="tocline0">15. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 536 <li class="tocline1">15.1 <a href="#header.age">Age</a></li> 537 <li class="tocline1">15.2 <a href="#header.cache-control">Cache-Control</a><ul class="toc"> 538 <li class="tocline1">15.2.1 <a href="#what.is.cacheable">What is Cacheable</a></li> 539 <li class="tocline1">15.2.2 <a href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></li> 540 <li class="tocline1">15.2.3 <a href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></li> 541 <li class="tocline1">15.2.4 <a href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></li> 542 <li class="tocline1">15.2.5 <a href="#no-transform.directive">No-Transform Directive</a></li> 543 <li class="tocline1">15.2.6 <a href="#cache.control.extensions">Cache Control Extensions</a></li> 492 544 </ul> 493 545 </li> 494 <li class="tocline1">2.2 <a href="#expiration.model">Expiration Model</a><ul class="toc"> 495 <li class="tocline1">2.2.1 <a href="#server-specified.expiration">Server-Specified Expiration</a></li> 496 <li class="tocline1">2.2.2 <a href="#heuristic.expiration">Heuristic Expiration</a></li> 497 <li class="tocline1">2.2.3 <a href="#age.calculations">Age Calculations</a></li> 498 <li class="tocline1">2.2.4 <a href="#expiration.calculations">Expiration Calculations</a></li> 499 <li class="tocline1">2.2.5 <a href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></li> 500 <li class="tocline1">2.2.6 <a href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></li> 501 </ul> 502 </li> 503 <li class="tocline1">2.3 <a href="#validation.model">Validation Model</a><ul class="toc"> 504 <li class="tocline1">2.3.1 <a href="#last-modified.dates">Last-Modified Dates</a></li> 505 <li class="tocline1">2.3.2 <a href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></li> 506 <li class="tocline1">2.3.3 <a href="#non-validating.conditionals">Non-validating Conditionals</a></li> 507 </ul> 508 </li> 509 <li class="tocline1">2.4 <a href="#response.cacheability">Response Cacheability</a></li> 510 <li class="tocline1">2.5 <a href="#constructing.responses.from.caches">Constructing Responses From Caches</a><ul class="toc"> 511 <li class="tocline1">2.5.1 <a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li> 512 <li class="tocline1">2.5.2 <a href="#non-modifiable.headers">Non-modifiable Headers</a></li> 513 <li class="tocline1">2.5.3 <a href="#combining.headers">Combining Headers</a></li> 514 </ul> 515 </li> 516 <li class="tocline1">2.6 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 517 <li class="tocline1">2.7 <a href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></li> 518 <li class="tocline1">2.8 <a href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></li> 519 <li class="tocline1">2.9 <a href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></li> 520 <li class="tocline1">2.10 <a href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></li> 521 <li class="tocline1">2.11 <a href="#write-through.mandatory">Write-Through Mandatory</a></li> 522 <li class="tocline1">2.12 <a href="#cache.replacement">Cache Replacement</a></li> 523 <li class="tocline1">2.13 <a href="#history.lists">History Lists</a></li> 546 <li class="tocline1">15.3 <a href="#header.expires">Expires</a></li> 547 <li class="tocline1">15.4 <a href="#header.pragma">Pragma</a></li> 548 <li class="tocline1">15.5 <a href="#header.vary">Vary</a></li> 549 <li class="tocline1">15.6 <a href="#header.warning">Warning</a></li> 524 550 </ul> 525 551 </li> 526 <li class="tocline0">3. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 527 <li class="tocline1">3.1 <a href="#header.age">Age</a></li> 528 <li class="tocline1">3.2 <a href="#header.cache-control">Cache-Control</a><ul class="toc"> 529 <li class="tocline1">3.2.1 <a href="#what.is.cacheable">What is Cacheable</a></li> 530 <li class="tocline1">3.2.2 <a href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></li> 531 <li class="tocline1">3.2.3 <a href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></li> 532 <li class="tocline1">3.2.4 <a href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></li> 533 <li class="tocline1">3.2.5 <a href="#no-transform.directive">No-Transform Directive</a></li> 534 <li class="tocline1">3.2.6 <a href="#cache.control.extensions">Cache Control Extensions</a></li> 535 </ul> 536 </li> 537 <li class="tocline1">3.3 <a href="#header.expires">Expires</a></li> 538 <li class="tocline1">3.4 <a href="#header.pragma">Pragma</a></li> 539 <li class="tocline1">3.5 <a href="#header.vary">Vary</a></li> 540 <li class="tocline1">3.6 <a href="#header.warning">Warning</a></li> 541 </ul> 542 </li> 543 <li class="tocline0">4. <a href="#IANA.considerations">IANA Considerations</a></li> 544 <li class="tocline0">5. <a href="#security.considerations">Security Considerations</a></li> 545 <li class="tocline0">6. <a href="#ack">Acknowledgments</a></li> 546 <li class="tocline0">7. <a href="#rfc.references">References</a><ul class="toc"> 547 <li class="tocline1">7.1 <a href="#rfc.references.1">Normative References</a></li> 548 <li class="tocline1">7.2 <a href="#rfc.references.2">Informative References</a></li> 552 <li class="tocline0">16. <a href="#IANA.considerations">IANA Considerations</a></li> 553 <li class="tocline0">17. <a href="#security.considerations">Security Considerations</a></li> 554 <li class="tocline0">18. <a href="#ack">Acknowledgments</a></li> 555 <li class="tocline0">19. <a href="#rfc.references">References</a><ul class="toc"> 556 <li class="tocline1">19.1 <a href="#rfc.references.1">Normative References</a></li> 557 <li class="tocline1">19.2 <a href="#rfc.references.2">Informative References</a></li> 549 558 </ul> 550 559 </li> … … 563 572 <li class="tocline0"><a href="#rfc.index">Index</a></li> 564 573 </ul> 565 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 566 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to caching response messages. Right now it only includes the extracted relevant 567 sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> without edit. 568 </p> 569 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> 570 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 571 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 572 </p> 573 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant." 574 </p> 575 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.terminology" href="#intro.terminology">Terminology</a></h2> 576 <p id="rfc.section.1.2.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.</p> 577 <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.1"></span> <dfn>cache</dfn> 578 </p> 579 <dl class="empty"> 580 <dd>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. 581 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 582 requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. 583 </dd> 584 </dl> 585 <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.c.2"></span> <dfn>cacheable</dfn> 586 </p> 587 <dl class="empty"> 588 <dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 589 The rules for determining the cacheability of HTTP responses are defined in <a href="#caching" title="Caching in HTTP">Section 2</a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular 590 request. 591 </dd> 592 </dl> 593 <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 594 </p> 595 <dl class="empty"> 596 <dd>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more 597 proxies. A response is also first-hand if its validity has just been checked directly with the origin server. 598 </dd> 599 </dl> 600 <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.e.1"></span> <dfn>explicit expiration time</dfn> 601 </p> 602 <dl class="empty"> 603 <dd>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</dd> 604 </dl> 605 <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 606 </p> 607 <dl class="empty"> 608 <dd>An expiration time assigned by a cache when no explicit expiration time is available.</dd> 609 </dl> 610 <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 611 </p> 612 <dl class="empty"> 613 <dd>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</dd> 614 </dl> 615 <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 616 </p> 617 <dl class="empty"> 618 <dd>The length of time between the generation of a response and its expiration time.</dd> 619 </dl> 620 <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 621 </p> 622 <dl class="empty"> 623 <dd>A response is fresh if its age has not yet exceeded its freshness lifetime.</dd> 624 </dl> 625 <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.s.1"></span> <dfn>stale</dfn> 626 </p> 627 <dl class="empty"> 628 <dd>A response is stale if its age has passed its freshness lifetime.</dd> 629 </dl> 630 <p id="rfc.section.1.2.p.11"> <span id="rfc.iref.s.2"></span> <dfn>semantically transparent</dfn> 631 </p> 632 <dl class="empty"> 633 <dd>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither 634 the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the 635 client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been 636 handled directly by the origin server. 637 </dd> 638 </dl> 639 <p id="rfc.section.1.2.p.12"> <span id="rfc.iref.v.1"></span> <dfn>validator</dfn> 640 </p> 641 <dl class="empty"> 642 <dd>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent 643 copy of an entity. 644 </dd> 645 </dl> 646 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="delta.seconds" href="#delta.seconds">Delta Seconds</a></h2> 647 <p id="rfc.section.1.3.p.1">Some HTTP header fields allow a time value to be specified as an integer number of seconds, represented in decimal, after 648 the time that the message was received. 649 </p> 650 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> delta-seconds = 1*DIGIT 651 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching" href="#caching">Caching in HTTP</a></h1> 652 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="caching.overview" href="#caching.overview">Overview</a></h2> 653 <p id="rfc.section.2.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. 574 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="caching" href="#caching">Introduction</a></h1> 575 <p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. 654 576 The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements 655 577 are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the 656 basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc. 657 </p> 658 <p id="rfc.section.2.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate 578 basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc. This document 579 defines aspects of HTTP related to caching response messages. 580 </p> 581 <div id="rfc.iref.c.1"></div> 582 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.purpose" href="#intro.purpose">Purpose</a></h2> 583 <p id="rfc.section.1.1.p.1">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache 584 stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. 585 Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. 586 </p> 587 <p id="rfc.section.1.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate 659 588 the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former 660 589 reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose 661 (see <a href="#expiration.model" title="Expiration Model">Section 2.2</a>). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see <a href="#validation.model" title="Validation Model">Section 2.3</a>). 662 </p> 663 <p id="rfc.section.2.1.p.3">Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic 664 transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. 665 However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications 590 (see <a href="#expiration.model" title="Expiration Model">Section 3</a>). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see <a href="#validation.model" title="Validation Model">Section 4</a>). 591 </p> 592 <div id="rfc.iref.s.1"></div> 593 <p id="rfc.section.1.1.p.3">A cache behaves in a "<dfn>semantically transparent</dfn>" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server, 594 except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except 595 for hop-by-hop headers) that it would have received had its request been handled directly by the origin server. 596 </p> 597 <p id="rfc.section.1.1.p.4">In an ideal world, all interactions with an HTTP cache would be semantically transparent. However, for some resources, semantic 598 transparency is not always necessary and can be effectively traded for the sake of bandwidth scaling, disconnected operation, 599 and high availability. HTTP/1.1 allows origin servers, caches, and clients to explicitly reduce transparency when necessary. 600 However, because non-transparent operation may confuse non-expert users and might be incompatible with certain server applications 666 601 (such as those for ordering merchandise), the protocol requires that transparency be relaxed 667 602 </p> … … 670 605 <li>only with an explicit warning to the end user when relaxed by cache or client</li> 671 606 </ul> 672 <p id="rfc.section. 2.1.p.4">Therefore, the HTTP/1.1 protocolprovides these important elements: </p>607 <p id="rfc.section.1.1.p.5">Therefore, HTTP/1.1 provides these important elements: </p> 673 608 <ol> 674 609 <li>Protocol features that provide full semantic transparency when this is required by all parties.</li> … … 678 613 </li> 679 614 </ol> 680 <p id="rfc.section. 2.1.p.5">A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. </p>615 <p id="rfc.section.1.1.p.6">A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. </p> 681 616 <dl class="empty"> 682 617 <dd> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification. … … 685 620 </dd> 686 621 </dl> 687 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h3> 688 <p id="rfc.section.2.1.1.p.1">A correct cache <em class="bcp14">MUST</em> respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see Sections <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a>, and <a href="#cache.replacement" title="Cache Replacement">2.12</a>) which meets one of the following conditions: 622 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.terminology" href="#intro.terminology">Terminology</a></h2> 623 <p id="rfc.section.1.2.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, HTTP caching.</p> 624 <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.2"></span> <dfn>cacheable</dfn> 625 </p> 626 <dl class="empty"> 627 <dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 628 Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular 629 request. 630 </dd> 631 </dl> 632 <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 633 </p> 634 <dl class="empty"> 635 <dd>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more 636 proxies. A response is also first-hand if its validity has just been checked directly with the origin server. 637 </dd> 638 </dl> 639 <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.e.1"></span> <dfn>explicit expiration time</dfn> 640 </p> 641 <dl class="empty"> 642 <dd>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</dd> 643 </dl> 644 <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 645 </p> 646 <dl class="empty"> 647 <dd>An expiration time assigned by a cache when no explicit expiration time is available.</dd> 648 </dl> 649 <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 650 </p> 651 <dl class="empty"> 652 <dd>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</dd> 653 </dl> 654 <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 655 </p> 656 <dl class="empty"> 657 <dd>The length of time between the generation of a response and its expiration time.</dd> 658 </dl> 659 <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 660 </p> 661 <dl class="empty"> 662 <dd>A response is fresh if its age has not yet exceeded its freshness lifetime.</dd> 663 </dl> 664 <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.s.2"></span> <dfn>stale</dfn> 665 </p> 666 <dl class="empty"> 667 <dd>A response is stale if its age has passed its freshness lifetime.</dd> 668 </dl> 669 <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.v.1"></span> <dfn>validator</dfn> 670 </p> 671 <dl class="empty"> 672 <dd>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent 673 copy of an entity. 674 </dd> 675 </dl> 676 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> 677 <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 678 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 679 </p> 680 <p id="rfc.section.1.3.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant." 681 </p> 682 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Overview</a></h1> 683 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h2> 684 <p id="rfc.section.2.1.p.1">A correct cache <em class="bcp14">MUST</em> respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see Sections <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">3.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">3.6</a>, and <a href="#cache.replacement" title="Cache Replacement">13</a>) which meets one of the following conditions: 689 685 </p> 690 686 <ol> 691 687 <li>It has been checked for equivalence with what the origin server would have returned by revalidating the response with the 692 origin server (<a href="#validation.model" title="Validation Model">Section 2.3</a>);693 </li> 694 <li>It is "fresh enough" (see <a href="#expiration.model" title="Expiration Model">Section 2.2</a>). In the default case, this means it meets the least restrictive freshness requirement of the client, origin server, and695 cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 3.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is688 origin server (<a href="#validation.model" title="Validation Model">Section 4</a>); 689 </li> 690 <li>It is "fresh enough" (see <a href="#expiration.model" title="Expiration Model">Section 3</a>). In the default case, this means it meets the least restrictive freshness requirement of the client, origin server, and 691 cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 15.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is 696 692 not "fresh enough" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered 697 circumstances the cache <em class="bcp14">MAY</em> still return the response with the appropriate Warning header (see Sections <a href="#exceptions.to.the.rules.and.warnings" title="Exceptions to the Rules and Warnings">2. 1.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">3.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive;698 see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 3.2</a>).693 circumstances the cache <em class="bcp14">MAY</em> still return the response with the appropriate Warning header (see Sections <a href="#exceptions.to.the.rules.and.warnings" title="Exceptions to the Rules and Warnings">2.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">15.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive; 694 see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 15.2</a>). 699 695 </li> 700 696 <li>It is an appropriate 304 (Not Modified), 305 (Use Proxy), or error (4xx or 5xx) response message.</li> 701 697 </ol> 702 <p id="rfc.section.2.1. 1.p.2">If the cache can not communicate with the origin server, then a correct cache <em class="bcp14">SHOULD</em> respond as above if the response can be correctly served from the cache; if not it <em class="bcp14">MUST</em> return an error or warning indicating that there was a communication failure.703 </p> 704 <p id="rfc.section.2.1. 1.p.3">If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward698 <p id="rfc.section.2.1.p.2">If the cache can not communicate with the origin server, then a correct cache <em class="bcp14">SHOULD</em> respond as above if the response can be correctly served from the cache; if not it <em class="bcp14">MUST</em> return an error or warning indicating that there was a communication failure. 699 </p> 700 <p id="rfc.section.2.1.p.3">If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward 705 701 to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache <em class="bcp14">SHOULD NOT</em> attempt to revalidate a response simply because that response became stale in transit; this might lead to an infinite loop. 706 702 A user agent that receives a stale response without a Warning <em class="bcp14">MAY</em> display a warning indication to the user. 707 703 </p> 708 <h 3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a> <a id="warnings" href="#warnings">Warnings</a></h3>709 <p id="rfc.section.2. 1.2.p.1">Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in <a href="#cache.correctness" title="Cache Correctness">Section 2.1.1</a>), it <em class="bcp14">MUST</em> attach a warning to that effect, using a Warning general-header. The Warning header and the currently defined warnings are710 described in <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>. The warning allows clients to take appropriate action.711 </p> 712 <p id="rfc.section.2. 1.2.p.2">Warnings <em class="bcp14">MAY</em> be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish704 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="warnings" href="#warnings">Warnings</a></h2> 705 <p id="rfc.section.2.2.p.1">Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in <a href="#cache.correctness" title="Cache Correctness">Section 2.1</a>), it <em class="bcp14">MUST</em> attach a warning to that effect, using a Warning general-header. The Warning header and the currently defined warnings are 706 described in <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 15.6</a>. The warning allows clients to take appropriate action. 707 </p> 708 <p id="rfc.section.2.2.p.2">Warnings <em class="bcp14">MAY</em> be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish 713 709 these responses from true failures. 714 710 </p> 715 <p id="rfc.section.2. 1.2.p.3">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning <em class="bcp14">MUST</em> or <em class="bcp14">MUST NOT</em> be deleted from a stored cache entry after a successful revalidation:716 </p> 717 <p id="rfc.section.2. 1.2.p.4"> </p>711 <p id="rfc.section.2.2.p.3">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning <em class="bcp14">MUST</em> or <em class="bcp14">MUST NOT</em> be deleted from a stored cache entry after a successful revalidation: 712 </p> 713 <p id="rfc.section.2.2.p.4"> </p> 718 714 <dl> 719 715 <dt>1xx</dt> … … 725 721 </dd> 726 722 </dl> 727 <p id="rfc.section.2. 1.2.p.5">See <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 3.6</a> for the definitions of the codes themselves.728 </p> 729 <p id="rfc.section.2. 1.2.p.6">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Warnings in responses723 <p id="rfc.section.2.2.p.5">See <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 15.6</a> for the definitions of the codes themselves. 724 </p> 725 <p id="rfc.section.2.2.p.6">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Warnings in responses 730 726 that are passed to HTTP/1.0 caches carry an extra warning-date field, which prevents a future HTTP/1.1 recipient from believing 731 727 an erroneously cached Warning. 732 728 </p> 733 <p id="rfc.section.2. 1.2.p.7">Warnings also carry a warning text. The text <em class="bcp14">MAY</em> be in any appropriate natural language (perhaps based on the client's Accept headers), and include an <em class="bcp14">OPTIONAL</em> indication of what character set is used.734 </p> 735 <p id="rfc.section.2. 1.2.p.8">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number.729 <p id="rfc.section.2.2.p.7">Warnings also carry a warning text. The text <em class="bcp14">MAY</em> be in any appropriate natural language (perhaps based on the client's Accept headers), and include an <em class="bcp14">OPTIONAL</em> indication of what character set is used. 730 </p> 731 <p id="rfc.section.2.2.p.8">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number. 736 732 For example, a server might provide the same warning with texts in both English and Basque. 737 733 </p> 738 <p id="rfc.section.2. 1.2.p.9">When multiple warnings are attached to a response, it might not be practical or reasonable to display all of them to the user.734 <p id="rfc.section.2.2.p.9">When multiple warnings are attached to a response, it might not be practical or reasonable to display all of them to the user. 739 735 This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but 740 736 does suggest some heuristics. 741 737 </p> 742 <h 3 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3</a> <a id="cache-control.mechanisms" href="#cache-control.mechanisms">Cache-control Mechanisms</a></h3>743 <p id="rfc.section.2. 1.3.p.1">The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches.738 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="cache-control.mechanisms" href="#cache-control.mechanisms">Cache-control Mechanisms</a></h2> 739 <p id="rfc.section.2.3.p.1">The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. 744 740 In some cases, a server or client might need to provide explicit directives to the HTTP caches. We use the Cache-Control header 745 741 for this purpose. 746 742 </p> 747 <p id="rfc.section.2. 1.3.p.2">The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These743 <p id="rfc.section.2.3.p.2">The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These 748 744 directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between 749 745 header values, the most restrictive interpretation is applied (that is, the one that is most likely to preserve semantic transparency). … … 751 747 (for example, "max-stale" or "public"). 752 748 </p> 753 <p id="rfc.section.2. 1.3.p.3">The cache-control directives are described in detail in <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 3.2</a>.754 </p> 755 <h 3 id="rfc.section.2.1.4"><a href="#rfc.section.2.1.4">2.1.4</a> <a id="explicit.ua.warnings" href="#explicit.ua.warnings">Explicit User Agent Warnings</a></h3>756 <p id="rfc.section.2. 1.4.p.1">Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent might allow749 <p id="rfc.section.2.3.p.3">The cache-control directives are described in detail in <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 15.2</a>. 750 </p> 751 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="explicit.ua.warnings" href="#explicit.ua.warnings">Explicit User Agent Warnings</a></h2> 752 <p id="rfc.section.2.4.p.1">Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent might allow 757 753 the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually 758 754 add "Cache-Control: max-stale=3600" to every request. The user agent <em class="bcp14">SHOULD NOT</em> default to either non-transparent behavior, or behavior that results in abnormally ineffective caching, but <em class="bcp14">MAY</em> be explicitly configured to do so by an explicit action of the user. 759 755 </p> 760 <p id="rfc.section.2. 1.4.p.2">If the user has overridden the basic caching mechanisms, the user agent <em class="bcp14">SHOULD</em> explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency756 <p id="rfc.section.2.4.p.2">If the user has overridden the basic caching mechanisms, the user agent <em class="bcp14">SHOULD</em> explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency 761 757 requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent 762 758 to determine if responses are stale or not, this indication need only be displayed when this actually happens. The indication 763 759 need not be a dialog box; it could be an icon (for example, a picture of a rotting fish) or some other indicator. 764 760 </p> 765 <p id="rfc.section.2. 1.4.p.3">If the user has overridden the caching mechanisms in a way that would abnormally reduce the effectiveness of caches, the user761 <p id="rfc.section.2.4.p.3">If the user has overridden the caching mechanisms in a way that would abnormally reduce the effectiveness of caches, the user 766 762 agent <em class="bcp14">SHOULD</em> continually indicate this state to the user (for example, by a display of a picture of currency in flames) so that the user 767 763 does not inadvertently consume excess resources or suffer from excessive latency. 768 764 </p> 769 <h 3 id="rfc.section.2.1.5"><a href="#rfc.section.2.1.5">2.1.5</a> <a id="exceptions.to.the.rules.and.warnings" href="#exceptions.to.the.rules.and.warnings">Exceptions to the Rules and Warnings</a></h3>770 <p id="rfc.section.2. 1.5.p.1">In some cases, the operator of a cache <em class="bcp14">MAY</em> choose to configure it to return stale responses even when not requested by clients. This decision ought not be made lightly,765 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="exceptions.to.the.rules.and.warnings" href="#exceptions.to.the.rules.and.warnings">Exceptions to the Rules and Warnings</a></h2> 766 <p id="rfc.section.2.5.p.1">In some cases, the operator of a cache <em class="bcp14">MAY</em> choose to configure it to return stale responses even when not requested by clients. This decision ought not be made lightly, 771 767 but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin 772 768 server. Whenever a cache returns a stale response, it <em class="bcp14">MUST</em> mark it as such (using a Warning header) enabling the client software to alert the user that there might be a potential problem. 773 769 </p> 774 <p id="rfc.section.2. 1.5.p.2">It also allows the user agent to take steps to obtain a first-hand or fresh response. For this reason, a cache <em class="bcp14">SHOULD NOT</em> return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for770 <p id="rfc.section.2.5.p.2">It also allows the user agent to take steps to obtain a first-hand or fresh response. For this reason, a cache <em class="bcp14">SHOULD NOT</em> return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for 775 771 technical or policy reasons. 776 772 </p> 777 <h 3 id="rfc.section.2.1.6"><a href="#rfc.section.2.1.6">2.1.6</a> <a id="client-controlled.behavior" href="#client-controlled.behavior">Client-controlled Behavior</a></h3>778 <p id="rfc.section.2. 1.6.p.1">While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are773 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="client-controlled.behavior" href="#client-controlled.behavior">Client-controlled Behavior</a></h2> 774 <p id="rfc.section.2.6.p.1">While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are 779 775 the primary source of expiration information, in some cases the client might need to control a cache's decision about whether 780 776 to return a cached response without validating it. Clients do this using several directives of the Cache-Control header. 781 777 </p> 782 <p id="rfc.section.2. 1.6.p.2">A client's request <em class="bcp14">MAY</em> specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the cache(s)778 <p id="rfc.section.2.6.p.2">A client's request <em class="bcp14">MAY</em> specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the cache(s) 783 779 to revalidate all responses. A client <em class="bcp14">MAY</em> also specify the minimum time remaining before a response expires. Both of these options increase constraints on the behavior 784 780 of caches, and so cannot further relax the cache's approximation of semantic transparency. 785 781 </p> 786 <p id="rfc.section.2. 1.6.p.3">A client <em class="bcp14">MAY</em> also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on782 <p id="rfc.section.2.6.p.3">A client <em class="bcp14">MAY</em> also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on 787 783 the caches, and so might violate the origin server's specified constraints on semantic transparency, but might be necessary 788 784 to support disconnected operation, or high availability in the face of poor connectivity. 789 785 </p> 790 <h 2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="expiration.model" href="#expiration.model">Expiration Model</a></h2>791 <h 3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="server-specified.expiration" href="#server-specified.expiration">Server-Specified Expiration</a></h3>792 <p id="rfc.section. 2.2.1.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding786 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="expiration.model" href="#expiration.model">Expiration Model</a></h1> 787 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="server-specified.expiration" href="#server-specified.expiration">Server-Specified Expiration</a></h2> 788 <p id="rfc.section.3.1.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding 793 789 requests is for an origin server to provide an explicit expiration time in the future, indicating that a response <em class="bcp14">MAY</em> be used to satisfy subsequent requests. In other words, a cache can return a fresh response without first contacting the server. 794 790 </p> 795 <p id="rfc.section. 2.2.1.p.2">Our expectation is that servers will assign future explicit expiration times to responses in the belief that the entity is791 <p id="rfc.section.3.1.p.2">Our expectation is that servers will assign future explicit expiration times to responses in the belief that the entity is 796 792 not likely to change, in a semantically significant way, before the expiration time is reached. This normally preserves semantic 797 793 transparency, as long as the server's expiration times are carefully chosen. 798 794 </p> 799 <p id="rfc.section. 2.2.1.p.3">The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately795 <p id="rfc.section.3.1.p.3">The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately 800 796 to the requesting client. 801 797 </p> 802 <p id="rfc.section. 2.2.1.p.4">If an origin server wishes to force a semantically transparent cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, and so the cache <em class="bcp14">SHOULD</em> validate it before using it for subsequent requests. See <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 3.2.4</a> for a more restrictive way to force revalidation.803 </p> 804 <p id="rfc.section. 2.2.1.p.5">If an origin server wishes to force any HTTP/1.1 cache, no matter how it is configured, to validate every request, it <em class="bcp14">SHOULD</em> use the "must-revalidate" cache-control directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section 3.2</a>).805 </p> 806 <p id="rfc.section. 2.2.1.p.6">Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.</p>807 <p id="rfc.section. 2.2.1.p.7">An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only798 <p id="rfc.section.3.1.p.4">If an origin server wishes to force a semantically transparent cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, and so the cache <em class="bcp14">SHOULD</em> validate it before using it for subsequent requests. See <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 15.2.4</a> for a more restrictive way to force revalidation. 799 </p> 800 <p id="rfc.section.3.1.p.5">If an origin server wishes to force any HTTP/1.1 cache, no matter how it is configured, to validate every request, it <em class="bcp14">SHOULD</em> use the "must-revalidate" cache-control directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section 15.2</a>). 801 </p> 802 <p id="rfc.section.3.1.p.6">Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.</p> 803 <p id="rfc.section.3.1.p.7">An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only 808 804 to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource 809 is initiated. See <a href="#history.lists" title="History Lists">Section 2.13</a> for an explanation of the difference between caches and history mechanisms.810 </p> 811 <h 3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> <a id="heuristic.expiration" href="#heuristic.expiration">Heuristic Expiration</a></h3>812 <p id="rfc.section. 2.2.2.p.1">Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times,805 is initiated. See <a href="#history.lists" title="History Lists">Section 14</a> for an explanation of the difference between caches and history mechanisms. 806 </p> 807 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="heuristic.expiration" href="#heuristic.expiration">Heuristic Expiration</a></h2> 808 <p id="rfc.section.3.2.p.1">Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, 813 809 employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. 814 810 The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. … … 816 812 origin servers to provide explicit expiration times as much as possible. 817 813 </p> 818 <h 3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a> <a id="age.calculations" href="#age.calculations">Age Calculations</a></h3>819 <p id="rfc.section. 2.2.3.p.1">In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. We discuss how820 to calculate the latter in <a href="#expiration.calculations" title="Expiration Calculations">Section 2.2.4</a>; this section describes how to calculate the age of a response or cache entry.821 </p> 822 <p id="rfc.section. 2.2.3.p.2">In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation."814 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="age.calculations" href="#age.calculations">Age Calculations</a></h2> 815 <p id="rfc.section.3.3.p.1">In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. We discuss how 816 to calculate the latter in <a href="#expiration.calculations" title="Expiration Calculations">Section 3.4</a>; this section describes how to calculate the age of a response or cache entry. 817 </p> 818 <p id="rfc.section.3.3.p.2">In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." 823 819 Hosts that use HTTP, but especially hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a> or some similar protocol to synchronize their clocks to a globally accurate time standard. 824 820 </p> 825 <p id="rfc.section. 2.2.3.p.3">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response821 <p id="rfc.section.3.3.p.3">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response 826 822 was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations. 827 823 </p> 828 <p id="rfc.section. 2.2.3.p.4">HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The824 <p id="rfc.section.3.3.p.4">HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The 829 825 Age field value is the cache's estimate of the amount of time since the response was generated or revalidated by the origin 830 826 server. 831 827 </p> 832 <p id="rfc.section. 2.2.3.p.5">In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path828 <p id="rfc.section.3.3.p.5">In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path 833 829 from the origin server, plus the amount of time it has been in transit along network paths. 834 830 </p> 835 <p id="rfc.section. 2.2.3.p.6">We use the term "age_value" to denote the value of the Age header, in a form appropriate for arithmetic operations.</p>836 <p id="rfc.section. 2.2.3.p.7">A response's age can be calculated in two entirely independent ways: </p>831 <p id="rfc.section.3.3.p.6">We use the term "age_value" to denote the value of the Age header, in a form appropriate for arithmetic operations.</p> 832 <p id="rfc.section.3.3.p.7">A response's age can be calculated in two entirely independent ways: </p> 837 833 <ol> 838 834 <li>now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, … … 841 837 <li>age_value, if all of the caches along the response path implement HTTP/1.1.</li> 842 838 </ol> 843 <p id="rfc.section. 2.2.3.p.8">Given that we have two independent ways to compute the age of a response when it is received, we can combine these as</p>844 <div id="rfc.figure.u. 2"></div><pre class="text"> corrected_received_age = max(now - date_value, age_value)845 </pre><p id="rfc.section. 2.2.3.p.10">and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result.</p>846 <p id="rfc.section. 2.2.3.p.11">Because of network-imposed delays, some significant interval might pass between the time that a server generates a response839 <p id="rfc.section.3.3.p.8">Given that we have two independent ways to compute the age of a response when it is received, we can combine these as</p> 840 <div id="rfc.figure.u.1"></div><pre class="text"> corrected_received_age = max(now - date_value, age_value) 841 </pre><p id="rfc.section.3.3.p.10">and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result.</p> 842 <p id="rfc.section.3.3.p.11">Because of network-imposed delays, some significant interval might pass between the time that a server generates a response 847 843 and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low 848 844 ages. 849 845 </p> 850 <p id="rfc.section. 2.2.3.p.12">Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation,846 <p id="rfc.section.3.3.p.12">Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, 851 847 we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age 852 848 value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received. This algorithm 853 849 results in conservative behavior no matter how much delay is experienced. So, we compute: 854 850 </p> 855 <div id="rfc.figure.u. 3"></div><pre class="text"> corrected_initial_age = corrected_received_age851 <div id="rfc.figure.u.2"></div><pre class="text"> corrected_initial_age = corrected_received_age 856 852 + (now - request_time) 857 </pre><p id="rfc.section. 2.2.3.p.14">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>858 <p id="rfc.section. 2.2.3.p.15">Summary of age calculation algorithm, when a cache receives a response:</p>859 <div id="rfc.figure.u. 4"></div><pre class="text"> /*853 </pre><p id="rfc.section.3.3.p.14">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p> 854 <p id="rfc.section.3.3.p.15">Summary of age calculation algorithm, when a cache receives a response:</p> 855 <div id="rfc.figure.u.3"></div><pre class="text"> /* 860 856 * age_value 861 857 * is the value of Age: header received by the cache with … … 879 875 resident_time = now - response_time; 880 876 current_age = corrected_initial_age + resident_time; 881 </pre><p id="rfc.section. 2.2.3.p.17">The current_age of a cache entry is calculated by adding the amount of time (in seconds) since the cache entry was last validated877 </pre><p id="rfc.section.3.3.p.17">The current_age of a cache entry is calculated by adding the amount of time (in seconds) since the cache entry was last validated 882 878 by the origin server to the corrected_initial_age. When a response is generated from a cache entry, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the cache entry's current_age. 883 879 </p> 884 <p id="rfc.section. 2.2.3.p.18">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not880 <p id="rfc.section.3.3.p.18">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not 885 881 true, since the lack of an Age header field in a response does not imply that the response is first-hand unless all caches 886 882 along the request path are compliant with HTTP/1.1 (i.e., older HTTP caches did not implement the Age header field). 887 883 </p> 888 <h 3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a> <a id="expiration.calculations" href="#expiration.calculations">Expiration Calculations</a></h3>889 <p id="rfc.section. 2.2.4.p.1">In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is890 calculated as described in <a href="#age.calculations" title="Age Calculations">Section 2.2.3</a>; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion884 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="expiration.calculations" href="#expiration.calculations">Expiration Calculations</a></h2> 885 <p id="rfc.section.3.4.p.1">In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is 886 calculated as described in <a href="#age.calculations" title="Age Calculations">Section 3.3</a>; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion 891 887 below, the values can be represented in any form appropriate for arithmetic operations. 892 888 </p> 893 <p id="rfc.section. 2.2.4.p.2">We use the term "expires_value" to denote the value of the Expires header. We use the term "max_age_value" to denote an appropriate894 value of the number of seconds carried by the "max-age" directive of the Cache-Control header in a response (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>).895 </p> 896 <p id="rfc.section. 2.2.4.p.3">The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply:</p>897 <div id="rfc.figure.u. 5"></div><pre class="text"> freshness_lifetime = max_age_value898 </pre><p id="rfc.section. 2.2.4.p.5">Otherwise, if Expires is present in the response, the calculation is:</p>899 <div id="rfc.figure.u. 6"></div><pre class="text"> freshness_lifetime = expires_value - date_value900 </pre><p id="rfc.section. 2.2.4.p.7">Note that neither of these calculations is vulnerable to clock skew, since all of the information comes from the origin server.</p>901 <p id="rfc.section. 2.2.4.p.8">If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>) appears in the response, and the response does not include other restrictions on caching, the cache <em class="bcp14">MAY</em> compute a freshness lifetime using a heuristic. The cache <em class="bcp14">MUST</em> attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added.902 </p> 903 <p id="rfc.section. 2.2.4.p.9">Also, if the response does have a Last-Modified time, the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.904 </p> 905 <p id="rfc.section. 2.2.4.p.10">The calculation to determine if a response has expired is quite simple:</p>906 <div id="rfc.figure.u. 7"></div><pre class="text"> response_is_fresh = (freshness_lifetime > current_age)907 </pre><h 3 id="rfc.section.2.2.5"><a href="#rfc.section.2.2.5">2.2.5</a> <a id="disambiguating.expiration.values" href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></h3>908 <p id="rfc.section. 2.2.5.p.1">Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same889 <p id="rfc.section.3.4.p.2">We use the term "expires_value" to denote the value of the Expires header. We use the term "max_age_value" to denote an appropriate 890 value of the number of seconds carried by the "max-age" directive of the Cache-Control header in a response (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a>). 891 </p> 892 <p id="rfc.section.3.4.p.3">The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply:</p> 893 <div id="rfc.figure.u.4"></div><pre class="text"> freshness_lifetime = max_age_value 894 </pre><p id="rfc.section.3.4.p.5">Otherwise, if Expires is present in the response, the calculation is:</p> 895 <div id="rfc.figure.u.5"></div><pre class="text"> freshness_lifetime = expires_value - date_value 896 </pre><p id="rfc.section.3.4.p.7">Note that neither of these calculations is vulnerable to clock skew, since all of the information comes from the origin server.</p> 897 <p id="rfc.section.3.4.p.8">If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a>) appears in the response, and the response does not include other restrictions on caching, the cache <em class="bcp14">MAY</em> compute a freshness lifetime using a heuristic. The cache <em class="bcp14">MUST</em> attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added. 898 </p> 899 <p id="rfc.section.3.4.p.9">Also, if the response does have a Last-Modified time, the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. 900 </p> 901 <p id="rfc.section.3.4.p.10">The calculation to determine if a response has expired is quite simple:</p> 902 <div id="rfc.figure.u.6"></div><pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 903 </pre><h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="disambiguating.expiration.values" href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></h2> 904 <p id="rfc.section.3.5.p.1">Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same 909 905 resource that are different. 910 906 </p> 911 <p id="rfc.section. 2.2.5.p.2">If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache,912 and the Date header in its existing cache entry is newer than the Date on the new response, then the client <em class="bcp14">MAY</em> ignore the response. If so, it <em class="bcp14">MAY</em> retry the request with a "Cache-Control: max-age=0" directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section 3.2</a>), to force a check with the origin server.913 </p> 914 <p id="rfc.section. 2.2.5.p.3">If a cache has two fresh responses for the same representation with different validators, it <em class="bcp14">MUST</em> use the one with the more recent Date header. This situation might arise because the cache is pooling responses from other907 <p id="rfc.section.3.5.p.2">If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache, 908 and the Date header in its existing cache entry is newer than the Date on the new response, then the client <em class="bcp14">MAY</em> ignore the response. If so, it <em class="bcp14">MAY</em> retry the request with a "Cache-Control: max-age=0" directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section 15.2</a>), to force a check with the origin server. 909 </p> 910 <p id="rfc.section.3.5.p.3">If a cache has two fresh responses for the same representation with different validators, it <em class="bcp14">MUST</em> use the one with the more recent Date header. This situation might arise because the cache is pooling responses from other 915 911 caches, or because a client has asked for a reload or a revalidation of an apparently fresh cache entry. 916 912 </p> 917 <h 3 id="rfc.section.2.2.6"><a href="#rfc.section.2.2.6">2.2.6</a> <a id="disambiguating.multiple.responses" href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></h3>918 <p id="rfc.section. 2.2.6.p.1">Because a client might be receiving responses via multiple paths, so that some responses flow through one set of caches and913 <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a> <a id="disambiguating.multiple.responses" href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></h2> 914 <p id="rfc.section.3.6.p.1">Because a client might be receiving responses via multiple paths, so that some responses flow through one set of caches and 919 915 other responses flow through a different set of caches, a client might receive responses in an order different from that in 920 916 which the origin server sent them. We would like the client to use the most recently generated response, even if older responses 921 917 are still apparently fresh. 922 918 </p> 923 <p id="rfc.section. 2.2.6.p.2">Neither the entity tag nor the expiration value can impose an ordering on responses, since it is possible that a later response919 <p id="rfc.section.3.6.p.2">Neither the entity tag nor the expiration value can impose an ordering on responses, since it is possible that a later response 924 920 intentionally carries an earlier expiration time. The Date values are ordered to a granularity of one second. 925 921 </p> 926 <p id="rfc.section. 2.2.6.p.3">When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older922 <p id="rfc.section.3.6.p.3">When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older 927 923 than the one for the existing entry, then the client <em class="bcp14">SHOULD</em> repeat the request unconditionally, and include 928 924 </p> 929 <div id="rfc.figure.u. 8"></div><pre class="text"> Cache-Control: max-age=0930 </pre><p id="rfc.section. 2.2.6.p.5">to force any intermediate caches to validate their copies directly with the origin server, or</p>931 <div id="rfc.figure.u. 9"></div><pre class="text"> Cache-Control: no-cache932 </pre><p id="rfc.section. 2.2.6.p.7">to force any intermediate caches to obtain a new copy from the origin server.</p>933 <p id="rfc.section. 2.2.6.p.8">If the Date values are equal, then the client <em class="bcp14">MAY</em> use either response (or <em class="bcp14">MAY</em>, if it is being extremely prudent, request a new response). Servers <em class="bcp14">MUST NOT</em> depend on clients being able to choose deterministically between responses generated during the same second, if their expiration925 <div id="rfc.figure.u.7"></div><pre class="text"> Cache-Control: max-age=0 926 </pre><p id="rfc.section.3.6.p.5">to force any intermediate caches to validate their copies directly with the origin server, or</p> 927 <div id="rfc.figure.u.8"></div><pre class="text"> Cache-Control: no-cache 928 </pre><p id="rfc.section.3.6.p.7">to force any intermediate caches to obtain a new copy from the origin server.</p> 929 <p id="rfc.section.3.6.p.8">If the Date values are equal, then the client <em class="bcp14">MAY</em> use either response (or <em class="bcp14">MAY</em>, if it is being extremely prudent, request a new response). Servers <em class="bcp14">MUST NOT</em> depend on clients being able to choose deterministically between responses generated during the same second, if their expiration 934 930 times overlap. 935 931 </p> 936 <h 2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2>937 <p id="rfc.section. 2.3.p.1">When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the932 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="validation.model" href="#validation.model">Validation Model</a></h1> 933 <p id="rfc.section.4.p.1">When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the 938 934 origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call 939 935 this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if … … 941 937 HTTP/1.1 protocol supports the use of conditional methods. 942 938 </p> 943 <p id="rfc.section. 2.3.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server939 <p id="rfc.section.4.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server 944 940 generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user 945 941 agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated 946 942 validator in the request. 947 943 </p> 948 <p id="rfc.section. 2.3.p.3">The server then checks that validator against the current validator for the entity, and, if they match (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), it responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response944 <p id="rfc.section.4.p.3">The server then checks that validator against the current validator for the entity, and, if they match (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), it responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response 949 945 (including entity-body). Thus, we avoid transmitting the full response if the validator matches, and we avoid an extra round 950 946 trip if it does not match. 951 947 </p> 952 <p id="rfc.section. 2.3.p.4">In HTTP/1.1, a conditional request looks exactly the same as a normal request for the same resource, except that it carries948 <p id="rfc.section.4.p.4">In HTTP/1.1, a conditional request looks exactly the same as a normal request for the same resource, except that it carries 953 949 a special header (which includes the validator) that implicitly turns the method (usually, GET) into a conditional. 954 950 </p> 955 <p id="rfc.section. 2.3.p.5">The protocol includes both positive and negative senses of cache-validating conditions. That is, it is possible to request951 <p id="rfc.section.4.p.5">The protocol includes both positive and negative senses of cache-validating conditions. That is, it is possible to request 956 952 either that a method be performed if and only if a validator matches or if and only if no validators match. 957 953 </p> … … 962 958 </dd> 963 959 </dl> 964 <h 3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="last-modified.dates" href="#last-modified.dates">Last-Modified Dates</a></h3>965 <p id="rfc.section. 2.3.1.p.1">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered960 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="last-modified.dates" href="#last-modified.dates">Last-Modified Dates</a></h2> 961 <p id="rfc.section.4.1.p.1">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered 966 962 to be valid if the entity has not been modified since the Last-Modified value. 967 963 </p> 968 <h 3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="entity.tag.cache.validators" href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></h3>969 <p id="rfc.section. 2.3.2.p.1">The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable964 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="entity.tag.cache.validators" href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></h2> 965 <p id="rfc.section.4.2.p.1">The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable 970 966 validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date 971 967 values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification 972 968 dates. 973 969 </p> 974 <p id="rfc.section. 2.3.2.p.2">Entity Tags are described in <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. The headers used with entity tags are described in <a href="p4-conditional.html#header.fields" title="Header Field Definitions">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.975 </p> 976 <h 3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h3>977 <p id="rfc.section. 2.3.3.p.1">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an970 <p id="rfc.section.4.2.p.2">Entity Tags are described in <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. The headers used with entity tags are described in <a href="p4-conditional.html#header.fields" title="Header Field Definitions">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 971 </p> 972 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h2> 973 <p id="rfc.section.4.3.p.1">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an 978 974 appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality 979 975 would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0) 980 976 are never used for purposes of validating a cache entry. 981 977 </p> 982 <h 2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>983 <p id="rfc.section. 2.4.p.1">Unless specifically constrained by a cache-control (<a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">Section 3.2</a>) directive, a caching system <em class="bcp14">MAY</em> always store a successful response (see <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">Section 2.8</a>) as a cache entry, <em class="bcp14">MAY</em> return it without validation if it is fresh, and <em class="bcp14">MAY</em> return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with978 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h1> 979 <p id="rfc.section.5.p.1">Unless specifically constrained by a cache-control (<a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">Section 15.2</a>) directive, a caching system <em class="bcp14">MAY</em> always store a successful response (see <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">Section 9</a>) as a cache entry, <em class="bcp14">MAY</em> return it without validation if it is fresh, and <em class="bcp14">MAY</em> return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with 984 980 a response, we do not expect it to be cached, but certain caches <em class="bcp14">MAY</em> violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that 985 981 such a response was taken from a cache by comparing the Date header to the current time. … … 989 985 </dd> 990 986 </dl> 991 <p id="rfc.section. 2.4.p.2">However, in some cases it might be inappropriate for a cache to retain an entity, or to return it in response to a subsequent987 <p id="rfc.section.5.p.2">However, in some cases it might be inappropriate for a cache to retain an entity, or to return it in response to a subsequent 992 988 request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security 993 989 or privacy considerations. Certain cache-control directives are therefore provided so that the server can indicate that certain 994 990 resource entities, or portions thereof, are not to be cached regardless of other considerations. 995 991 </p> 996 <p id="rfc.section. 2.4.p.3">Note that <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a> normally prevents a shared cache from saving and returning a response to a previous request if that request included an Authorization992 <p id="rfc.section.5.p.3">Note that <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a> normally prevents a shared cache from saving and returning a response to a previous request if that request included an Authorization 997 993 header. 998 994 </p> 999 <p id="rfc.section. 2.4.p.4">A response received with a status code of 200, 203, 206, 300, 301 or 410 <em class="bcp14">MAY</em> be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control995 <p id="rfc.section.5.p.4">A response received with a status code of 200, 203, 206, 300, 301 or 410 <em class="bcp14">MAY</em> be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control 1000 996 directive prohibits caching. However, a cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. 1001 997 </p> 1002 <p id="rfc.section. 2.4.p.5">A response received with any other status code (e.g. status codes 302 and 307) <em class="bcp14">MUST NOT</em> be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly1003 allow it. For example, these include the following: an Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 3.3</a>); a "max-age", "s-maxage", "must-revalidate", "proxy-revalidate", "public" or "private" cache-control directive (<a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">Section 3.2</a>).1004 </p> 1005 <h 2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses From Caches</a></h2>1006 <p id="rfc.section. 2.5.p.1">The purpose of an HTTP cache is to store information received in response to requests for use in responding to future requests.998 <p id="rfc.section.5.p.5">A response received with any other status code (e.g. status codes 302 and 307) <em class="bcp14">MUST NOT</em> be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly 999 allow it. For example, these include the following: an Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 15.3</a>); a "max-age", "s-maxage", "must-revalidate", "proxy-revalidate", "public" or "private" cache-control directive (<a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">Section 15.2</a>). 1000 </p> 1001 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses From Caches</a></h1> 1002 <p id="rfc.section.6.p.1">The purpose of an HTTP cache is to store information received in response to requests for use in responding to future requests. 1007 1003 In many cases, a cache simply returns the appropriate parts of a response to the requester. However, if the cache holds a 1008 1004 cache entry based on a previous response, it might have to combine parts of a new response with what is held in the cache 1009 1005 entry. 1010 1006 </p> 1011 <h 3 id="rfc.section.2.5.1"><a href="#rfc.section.2.5.1">2.5.1</a> <a id="end-to-end.and.hop-by-hop.headers" href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></h3>1012 <p id="rfc.section. 2.5.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: </p>1007 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="end-to-end.and.hop-by-hop.headers" href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></h2> 1008 <p id="rfc.section.6.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: </p> 1013 1009 <ul> 1014 1010 <li>End-to-end headers, which are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses <em class="bcp14">MUST</em> be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry. … … 1018 1014 </li> 1019 1015 </ul> 1020 <p id="rfc.section. 2.5.1.p.2">The following HTTP/1.1 headers are hop-by-hop headers: </p>1016 <p id="rfc.section.6.1.p.2">The following HTTP/1.1 headers are hop-by-hop headers: </p> 1021 1017 <ul> 1022 1018 <li>Connection</li> … … 1029 1025 <li>Upgrade</li> 1030 1026 </ul> 1031 <p id="rfc.section. 2.5.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p>1032 <p id="rfc.section. 2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1033 </p> 1034 <h 3 id="rfc.section.2.5.2"><a href="#rfc.section.2.5.2">2.5.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h3>1035 <p id="rfc.section. 2.5.2.p.1">Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers.1027 <p id="rfc.section.6.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p> 1028 <p id="rfc.section.6.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1029 </p> 1030 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h2> 1031 <p id="rfc.section.6.2.p.1">Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers. 1036 1032 A transparent proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that. 1037 1033 </p> 1038 <p id="rfc.section. 2.5.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:1034 <p id="rfc.section.6.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 1039 1035 </p> 1040 1036 <ul> … … 1044 1040 <li>Last-Modified</li> 1045 1041 </ul> 1046 <p id="rfc.section. 2.5.2.p.3">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response:1042 <p id="rfc.section.6.2.p.3">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: 1047 1043 </p> 1048 1044 <ul> 1049 1045 <li>Expires</li> 1050 1046 </ul> 1051 <p id="rfc.section. 2.5.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header in that response.1052 </p> 1053 <p id="rfc.section. 2.5.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:1047 <p id="rfc.section.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header in that response. 1048 </p> 1049 <p id="rfc.section.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: 1054 1050 </p> 1055 1051 <ul> … … 1058 1054 <li>Content-Type</li> 1059 1055 </ul> 1060 <p id="rfc.section. 2.5.2.p.6">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 3.6</a>).1056 <p id="rfc.section.6.2.p.6">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 15.6</a>). 1061 1057 </p> 1062 1058 <dl class="empty"> … … 1065 1061 </dd> 1066 1062 </dl> 1067 <p id="rfc.section. 2.5.2.p.7">The Content-Length field of a request or response is added or deleted according to the rules in <a href="p1-messaging.html#message.length" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="p3-payload.html#entity.length" title="Entity Length">Section 3.2.2</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) of the entity-body, although it <em class="bcp14">MAY</em> change the transfer-length (<a href="p1-messaging.html#message.length" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1068 </p> 1069 <h 3 id="rfc.section.2.5.3"><a href="#rfc.section.2.5.3">2.5.3</a> <a id="combining.headers" href="#combining.headers">Combining Headers</a></h3>1070 <p id="rfc.section. 2.5.3.p.1">When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial1063 <p id="rfc.section.6.2.p.7">The Content-Length field of a request or response is added or deleted according to the rules in <a href="p1-messaging.html#message.length" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="p3-payload.html#entity.length" title="Entity Length">Section 3.2.2</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) of the entity-body, although it <em class="bcp14">MAY</em> change the transfer-length (<a href="p1-messaging.html#message.length" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1064 </p> 1065 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="combining.headers" href="#combining.headers">Combining Headers</a></h2> 1066 <p id="rfc.section.6.3.p.1">When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial 1071 1067 Content) response, the cache then constructs a response to send to the requesting client. 1072 1068 </p> 1073 <p id="rfc.section. 2.5.3.p.2">If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this1069 <p id="rfc.section.6.3.p.2">If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this 1074 1070 outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache <em class="bcp14">MAY</em> combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body 1075 1071 of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). 1076 1072 </p> 1077 <p id="rfc.section. 2.5.3.p.3">The end-to-end headers stored in the cache entry are used for the constructed response, except that </p>1073 <p id="rfc.section.6.3.p.3">The end-to-end headers stored in the cache entry are used for the constructed response, except that </p> 1078 1074 <ul> 1079 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted from the cache entry and the forwarded response.1075 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 15.6</a>) <em class="bcp14">MUST</em> be deleted from the cache entry and the forwarded response. 1080 1076 </li> 1081 1077 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the cache entry and the forwarded response. … … 1084 1080 </li> 1085 1081 </ul> 1086 <p id="rfc.section. 2.5.3.p.4">Unless the cache decides to remove the cache entry, it <em class="bcp14">MUST</em> also replace the end-to-end headers stored with the cache entry with corresponding headers received in the incoming response,1082 <p id="rfc.section.6.3.p.4">Unless the cache decides to remove the cache entry, it <em class="bcp14">MUST</em> also replace the end-to-end headers stored with the cache entry with corresponding headers received in the incoming response, 1087 1083 except for Warning headers as described immediately above. If a header field-name in the incoming response matches more than 1088 1084 one header in the cache entry, all such old headers <em class="bcp14">MUST</em> be replaced. 1089 1085 </p> 1090 <p id="rfc.section. 2.5.3.p.5">In other words, the set of end-to-end headers received in the incoming response overrides all corresponding end-to-end headers1086 <p id="rfc.section.6.3.p.5">In other words, the set of end-to-end headers received in the incoming response overrides all corresponding end-to-end headers 1091 1087 stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden). 1092 1088 </p> … … 1098 1094 </dd> 1099 1095 </dl> 1100 <h 2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>1101 <p id="rfc.section. 2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache1102 can use the response for subsequent requests. See <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a> for use of the Vary header field by servers.1103 </p> 1104 <p id="rfc.section. 2.6.p.2">A server <em class="bcp14">SHOULD</em> use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations1096 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h1> 1097 <p id="rfc.section.7.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache 1098 can use the response for subsequent requests. See <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 15.5</a> for use of the Vary header field by servers. 1099 </p> 1100 <p id="rfc.section.7.p.2">A server <em class="bcp14">SHOULD</em> use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations 1105 1101 of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known 1106 1102 as the "selecting" request-headers. 1107 1103 </p> 1108 <p id="rfc.section. 2.6.p.3">When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header1104 <p id="rfc.section.7.p.3">When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header 1109 1105 field, the cache <em class="bcp14">MUST NOT</em> use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the 1110 1106 new request match the corresponding stored request-headers in the original request. 1111 1107 </p> 1112 <p id="rfc.section. 2.6.p.4">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first1108 <p id="rfc.section.7.p.4">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 1113 1109 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space 1114 1110 (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same 1115 1111 field name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1116 1112 </p> 1117 <p id="rfc.section. 2.6.p.5">A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted1113 <p id="rfc.section.7.p.5">A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted 1118 1114 by the origin server. 1119 1115 </p> 1120 <p id="rfc.section. 2.6.p.6">If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request,1116 <p id="rfc.section.7.p.6">If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, 1121 1117 then the cache <em class="bcp14">MUST NOT</em> use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request 1122 1118 and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to 1123 1119 be used. 1124 1120 </p> 1125 <p id="rfc.section. 2.6.p.7">If an entity tag was assigned to a cached representation, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This1121 <p id="rfc.section.7.p.7">If an entity tag was assigned to a cached representation, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This 1126 1122 conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested 1127 1123 entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. 1128 1124 If the entity-tag of the new response matches that of an existing entry, the new response <em class="bcp14">SHOULD</em> be used to update the header fields of the existing entry, and the result <em class="bcp14">MUST</em> be returned to the client. 1129 1125 </p> 1130 <p id="rfc.section. 2.6.p.8">If any of the existing cache entries contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that entry.1131 </p> 1132 <p id="rfc.section. 2.6.p.9">If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same1126 <p id="rfc.section.7.p.8">If any of the existing cache entries contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that entry. 1127 </p> 1128 <p id="rfc.section.7.p.9">If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same 1133 1129 Request-URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing 1134 1130 entry, the existing entry <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache. 1135 1131 </p> 1136 <h 2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="shared.and.non-shared.caches" href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></h2>1137 <p id="rfc.section. 2.7.p.1">For reasons of security and privacy, it is necessary to make a distinction between "shared" and "non-shared" caches. A non-shared1132 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="shared.and.non-shared.caches" href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></h1> 1133 <p id="rfc.section.8.p.1">For reasons of security and privacy, it is necessary to make a distinction between "shared" and "non-shared" caches. A non-shared 1138 1134 cache is one that is accessible only to a single user. Accessibility in this case <em class="bcp14">SHOULD</em> be enforced by appropriate security mechanisms. All other caches are considered to be "shared." Other sections of this specification 1139 1135 place certain constraints on the operation of shared caches in order to prevent loss of privacy or failure of access controls. 1140 1136 </p> 1141 <h 2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></h2>1142 <p id="rfc.section. 2.8.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code.1137 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></h1> 1138 <p id="rfc.section.9.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. 1143 1139 A cache <em class="bcp14">MUST NOT</em> return a partial response using a status code of 200 (OK). 1144 1140 </p> 1145 <p id="rfc.section. 2.8.p.2">If a cache receives a 5xx response while attempting to revalidate an entry, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the cached entry includes the "must-revalidate" cache-control directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.8" title="Cache-Control">Section 3.2</a>).1146 </p> 1147 <h 2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a> <a id="side.effects.of.get.and.head" href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></h2>1148 <p id="rfc.section. 2.9.p.1">Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any1141 <p id="rfc.section.9.p.2">If a cache receives a 5xx response while attempting to revalidate an entry, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the cached entry includes the "must-revalidate" cache-control directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.8" title="Cache-Control">Section 15.2</a>). 1142 </p> 1143 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="side.effects.of.get.and.head" href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></h1> 1144 <p id="rfc.section.10.p.1">Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any 1149 1145 resources <em class="bcp14">SHOULD NOT</em> have side effects that would lead to erroneous behavior if these responses are taken from a cache. They <em class="bcp14">MAY</em> still have side effects, but a cache is not required to consider such side effects in its caching decisions. Caches are always 1150 1146 expected to observe an origin server's explicit restrictions on caching. 1151 1147 </p> 1152 <p id="rfc.section. 2.9.p.2">We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those1148 <p id="rfc.section.10.p.2">We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those 1153 1149 containing a "?" in the rel_path part) to perform operations with significant side effects, caches <em class="bcp14">MUST NOT</em> treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that 1154 1150 responses from HTTP/1.0 servers for such URIs <em class="bcp14">SHOULD NOT</em> be taken from a cache. See <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for related information. 1155 1151 </p> 1156 <h 2 id="rfc.section.2.10"><a href="#rfc.section.2.10">2.10</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></h2>1157 <p id="rfc.section. 2.10.p.1">The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries1152 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></h1> 1153 <p id="rfc.section.11.p.1">The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries 1158 1154 to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what 1159 1155 the origin server would return for a new request on that resource. 1160 1156 </p> 1161 <p id="rfc.section. 2.10.p.2">There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request1157 <p id="rfc.section.11.p.2">There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request 1162 1158 that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However, 1163 1159 several rules help reduce the likelihood of erroneous behavior. 1164 1160 </p> 1165 <p id="rfc.section. 2.10.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from1161 <p id="rfc.section.11.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from 1166 1162 its storage, or will mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response 1167 1163 to a subsequent request. 1168 1164 </p> 1169 <p id="rfc.section. 2.10.p.4">Some HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location1165 <p id="rfc.section.11.p.4">Some HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location 1170 1166 headers (if present). These methods are: 1171 1167 </p> … … 1175 1171 <li>POST</li> 1176 1172 </ul> 1177 <p id="rfc.section. 2.10.p.5">An invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service1173 <p id="rfc.section.11.p.5">An invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service 1178 1174 attacks. 1179 1175 </p> 1180 <p id="rfc.section. 2.10.p.6">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate any entities referred to by the Request-URI.1181 </p> 1182 <h 2 id="rfc.section.2.11"><a href="#rfc.section.2.11">2.11</a> <a id="write-through.mandatory" href="#write-through.mandatory">Write-Through Mandatory</a></h2>1183 <p id="rfc.section. 2.11.p.1">All methods that might be expected to cause modifications to the origin server's resources <em class="bcp14">MUST</em> be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache <em class="bcp14">MUST NOT</em> reply to such a request from a client before having transmitted the request to the inbound server, and having received a corresponding1176 <p id="rfc.section.11.p.6">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate any entities referred to by the Request-URI. 1177 </p> 1178 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="write-through.mandatory" href="#write-through.mandatory">Write-Through Mandatory</a></h1> 1179 <p id="rfc.section.12.p.1">All methods that might be expected to cause modifications to the origin server's resources <em class="bcp14">MUST</em> be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache <em class="bcp14">MUST NOT</em> reply to such a request from a client before having transmitted the request to the inbound server, and having received a corresponding 1184 1180 response from the inbound server. This does not prevent a proxy cache from sending a 100 (Continue) response before the inbound 1185 1181 server has sent its final reply. 1186 1182 </p> 1187 <p id="rfc.section. 2.11.p.2">The alternative (known as "write-back" or "copy-back" caching) is not allowed in HTTP/1.1, due to the difficulty of providing1183 <p id="rfc.section.12.p.2">The alternative (known as "write-back" or "copy-back" caching) is not allowed in HTTP/1.1, due to the difficulty of providing 1188 1184 consistent updates and the problems arising from server, cache, or network failure prior to write-back. 1189 1185 </p> 1190 <h 2 id="rfc.section.2.12"><a href="#rfc.section.2.12">2.12</a> <a id="cache.replacement" href="#cache.replacement">Cache Replacement</a></h2>1191 <p id="rfc.section. 2.12.p.1">If a new cacheable (see Sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">3.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">2.8</a>) response is received from a resource while any existing responses for the same resource are cached, the cache <em class="bcp14">SHOULD</em> use the new response to reply to the current request. It <em class="bcp14">MAY</em> insert it into cache storage and <em class="bcp14">MAY</em>, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response1192 to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section 2.5.3</a> apply.1186 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="cache.replacement" href="#cache.replacement">Cache Replacement</a></h1> 1187 <p id="rfc.section.13.p.1">If a new cacheable (see Sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">15.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">3.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">3.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">9</a>) response is received from a resource while any existing responses for the same resource are cached, the cache <em class="bcp14">SHOULD</em> use the new response to reply to the current request. It <em class="bcp14">MAY</em> insert it into cache storage and <em class="bcp14">MAY</em>, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response 1188 to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section 6.3</a> apply. 1193 1189 </p> 1194 1190 <dl class="empty"> … … 1196 1192 </dd> 1197 1193 </dl> 1198 <h 2 id="rfc.section.2.13"><a href="#rfc.section.2.13">2.13</a> <a id="history.lists" href="#history.lists">History Lists</a></h2>1199 <p id="rfc.section. 2.13.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity1194 <h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a id="history.lists" href="#history.lists">History Lists</a></h1> 1195 <p id="rfc.section.14.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity 1200 1196 retrieved earlier in a session. 1201 1197 </p> 1202 <p id="rfc.section. 2.13.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show1198 <p id="rfc.section.14.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show 1203 1199 exactly what the user saw at the time when the resource was retrieved. 1204 1200 </p> 1205 <p id="rfc.section. 2.13.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history1201 <p id="rfc.section.14.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history 1206 1202 documents. 1207 1203 </p> 1208 <p id="rfc.section. 2.13.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>1204 <p id="rfc.section.14.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p> 1209 1205 <dl class="empty"> 1210 1206 <dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors … … 1216 1212 </dd> 1217 1213 </dl> 1218 <h1 id="rfc.section. 3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>1219 <p id="rfc.section. 3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>1220 <p id="rfc.section. 3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1214 <h1 id="rfc.section.15"><a href="#rfc.section.15">15.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1215 <p id="rfc.section.15.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> 1216 <p id="rfc.section.15.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 1221 1217 receives the entity. 1222 1218 </p> 1223 1219 <div id="rfc.iref.a.2"></div> 1224 1220 <div id="rfc.iref.h.2"></div> 1225 <h2 id="rfc.section. 3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.age" href="#header.age">Age</a></h2>1226 <p id="rfc.section. 3.1.p.1">The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation)1221 <h2 id="rfc.section.15.1"><a href="#rfc.section.15.1">15.1</a> <a id="header.age" href="#header.age">Age</a></h2> 1222 <p id="rfc.section.15.1.p.1">The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) 1227 1223 was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. Age values 1228 are calculated as specified in <a href="#age.calculations" title="Age Calculations">Section 2.2.3</a>.1229 </p> 1230 <div id="rfc.figure.u. 10"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> Age = "Age" ":" age-value1224 are calculated as specified in <a href="#age.calculations" title="Age Calculations">Section 3.3</a>. 1225 </p> 1226 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> Age = "Age" ":" age-value 1231 1227 age-value = delta-seconds 1232 </pre><p id="rfc.section.3.1.p.3">Age values are non-negative decimal integers, representing time in seconds.</p> 1233 <p id="rfc.section.3.1.p.4">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, 1228 </pre><p id="rfc.section.15.1.p.3">Age values are non-negative decimal integers, representing time in seconds.</p> 1229 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.3"></span> delta-seconds = 1*DIGIT 1230 </pre><p id="rfc.section.15.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, 1234 1231 it <em class="bcp14">MUST</em> transmit an Age header with a value of 2147483648 (2^31). An HTTP/1.1 server that includes a cache <em class="bcp14">MUST</em> include an Age header field in every response generated from its own cache. Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range. 1235 1232 </p> 1236 1233 <div id="rfc.iref.c.3"></div> 1237 1234 <div id="rfc.iref.h.3"></div> 1238 <h2 id="rfc.section. 3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>1239 <p id="rfc.section. 3.2.p.1">The Cache-Control general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent1235 <h2 id="rfc.section.15.2"><a href="#rfc.section.15.2">15.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> 1236 <p id="rfc.section.15.2.p.1">The Cache-Control general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent 1240 1237 caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. 1241 1238 Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive … … 1243 1240 </p> 1244 1241 <dl class="empty"> 1245 <dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 3.4</a>).1246 </dd> 1247 </dl> 1248 <p id="rfc.section. 3.2.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives1242 <dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 15.4</a>). 1243 </dd> 1244 </dl> 1245 <p id="rfc.section.15.2.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives 1249 1246 might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for 1250 1247 a specific cache. … … 1256 1253 1257 1254 cache-request-directive = 1258 "no-cache" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 3.2.1</a>1259 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 3.2.2</a>1260 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>, <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">3.2.4</a>1261 | "max-stale" [ "=" delta-seconds ] ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>1262 | "min-fresh" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>1263 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 3.2.5</a>1264 | "only-if-cached" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 3.2.4</a>1265 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.6</a>1255 "no-cache" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 15.2.1</a> 1256 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 15.2.2</a> 1257 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a>, <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">15.2.4</a> 1258 | "max-stale" [ "=" delta-seconds ] ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a> 1259 | "min-fresh" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a> 1260 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 15.2.5</a> 1261 | "only-if-cached" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 15.2.4</a> 1262 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 15.2.6</a> 1266 1263 1267 1264 cache-response-directive = 1268 "public" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 3.2.1</a>1269 | "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; <a href="#what.is.cacheable" title="What is Cacheable">Section 3.2.1</a>1270 | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]; <a href="#what.is.cacheable" title="What is Cacheable">Section 3.2.1</a>1271 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 3.2.2</a>1272 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 3.2.5</a>1273 | "must-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 3.2.4</a>1274 | "proxy-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 3.2.4</a>1275 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>1276 | "s-maxage" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>1277 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.6</a>1265 "public" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 15.2.1</a> 1266 | "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; <a href="#what.is.cacheable" title="What is Cacheable">Section 15.2.1</a> 1267 | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]; <a href="#what.is.cacheable" title="What is Cacheable">Section 15.2.1</a> 1268 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 15.2.2</a> 1269 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 15.2.5</a> 1270 | "must-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 15.2.4</a> 1271 | "proxy-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 15.2.4</a> 1272 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a> 1273 | "s-maxage" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a> 1274 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 15.2.6</a> 1278 1275 1279 1276 cache-extension = token [ "=" ( token | quoted-string ) ] 1280 </pre><p id="rfc.section. 3.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When1277 </pre><p id="rfc.section.15.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When 1281 1278 such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest 1282 1279 of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol 1283 1280 might apply these directives to header fields not defined in HTTP/1.1. 1284 1281 </p> 1285 <p id="rfc.section. 3.2.p.5">The cache-control directives can be broken down into these general categories: </p>1282 <p id="rfc.section.15.2.p.5">The cache-control directives can be broken down into these general categories: </p> 1286 1283 <ul> 1287 1284 <li>Restrictions on what are cacheable; these may only be imposed by the origin server.</li> … … 1292 1289 <li>Extensions to the caching system.</li> 1293 1290 </ul> 1294 <h3 id="rfc.section. 3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="what.is.cacheable" href="#what.is.cacheable">What is Cacheable</a></h3>1295 <p id="rfc.section. 3.2.1.p.1">By default, a response is cacheable if the requirements of the request method, request header fields, and the response status1296 indicate that it is cacheable. <a href="#response.cacheability" title="Response Cacheability">Section 2.4</a> summarizes these defaults for cacheability. The following Cache-Control response directives allow an origin server to override1291 <h3 id="rfc.section.15.2.1"><a href="#rfc.section.15.2.1">15.2.1</a> <a id="what.is.cacheable" href="#what.is.cacheable">What is Cacheable</a></h3> 1292 <p id="rfc.section.15.2.1.p.1">By default, a response is cacheable if the requirements of the request method, request header fields, and the response status 1293 indicate that it is cacheable. <a href="#response.cacheability" title="Response Cacheability">Section 5</a> summarizes these defaults for cacheability. The following Cache-Control response directives allow an origin server to override 1297 1294 the default cacheability of a response: 1298 1295 </p> 1299 <p id="rfc.section. 3.2.1.p.2"> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.p.1"></span> public1296 <p id="rfc.section.15.2.1.p.2"> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.p.1"></span> public 1300 1297 </p> 1301 1298 <dl class="empty"> … … 1304 1301 </dd> 1305 1302 </dl> 1306 <p id="rfc.section. 3.2.1.p.3"> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.p.2"></span> private1303 <p id="rfc.section.15.2.1.p.3"> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.p.2"></span> private 1307 1304 </p> 1308 1305 <dl class="empty"> … … 1314 1311 </dd> 1315 1312 </dl> 1316 <p id="rfc.section. 3.2.1.p.4"> <span id="rfc.iref.c.6"></span> <span id="rfc.iref.n.1"></span> no-cache1313 <p id="rfc.section.15.2.1.p.4"> <span id="rfc.iref.c.6"></span> <span id="rfc.iref.n.1"></span> no-cache 1317 1314 </p> 1318 1315 <dl class="empty"> … … 1328 1325 </dd> 1329 1326 </dl> 1330 <h3 id="rfc.section. 3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="what.may.be.stored.by.caches" href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></h3>1331 <p id="rfc.section. 3.2.2.p.1"> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.n.2"></span> no-store1327 <h3 id="rfc.section.15.2.2"><a href="#rfc.section.15.2.2">15.2.2</a> <a id="what.may.be.stored.by.caches" href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></h3> 1328 <p id="rfc.section.15.2.2.p.1"> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.n.2"></span> no-store 1332 1329 </p> 1333 1330 <dl class="empty"> … … 1346 1343 </dd> 1347 1344 </dl> 1348 <h3 id="rfc.section. 3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="modifications.of.the.basic.expiration.mechanism" href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></h3>1349 <p id="rfc.section. 3.2.3.p.1">The expiration time of an entity <em class="bcp14">MAY</em> be specified by the origin server using the Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 3.3</a>). Alternatively, it <em class="bcp14">MAY</em> be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response,1345 <h3 id="rfc.section.15.2.3"><a href="#rfc.section.15.2.3">15.2.3</a> <a id="modifications.of.the.basic.expiration.mechanism" href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></h3> 1346 <p id="rfc.section.15.2.3.p.1">The expiration time of an entity <em class="bcp14">MAY</em> be specified by the origin server using the Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 15.3</a>). Alternatively, it <em class="bcp14">MAY</em> be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, 1350 1347 the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for 1351 1348 that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, 1352 1349 more restrictive cache directive is also present. 1353 1350 </p> 1354 <p id="rfc.section. 3.2.3.p.2">If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header,1351 <p id="rfc.section.15.2.3.p.2">If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, 1355 1352 even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer 1356 1353 expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches 1357 1354 improperly calculate ages or expiration times, perhaps due to desynchronized clocks. 1358 1355 </p> 1359 <p id="rfc.section. 3.2.3.p.3">Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being1356 <p id="rfc.section.15.2.3.p.3">Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being 1360 1357 equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response 1361 1358 does not include a Cache-Control header field, it <em class="bcp14">SHOULD</em> consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers. … … 1368 1365 </dd> 1369 1366 </dl> 1370 <p id="rfc.section. 3.2.3.p.4"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.s.3"></span> s-maxage1367 <p id="rfc.section.15.2.3.p.4"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.s.3"></span> s-maxage 1371 1368 </p> 1372 1369 <dl class="empty"> 1373 1370 <dd>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified 1374 1371 by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage 1375 directive also implies the semantics of the proxy-revalidate directive (see <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 3.2.4</a>), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first1372 directive also implies the semantics of the proxy-revalidate directive (see <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 15.2.4</a>), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first 1376 1373 revalidating it with the origin server. The s-maxage directive is always ignored by a private cache. 1377 1374 </dd> 1378 1375 </dl> 1379 <p id="rfc.section. 3.2.3.p.5">Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin1376 <p id="rfc.section.15.2.3.p.5">Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin 1380 1377 server wishing to use a cache-control directive that restricts, but does not prevent, caching by an HTTP/1.1-compliant cache <em class="bcp14">MAY</em> exploit the requirement that the max-age directive overrides the Expires header, and the fact that pre-HTTP/1.1-compliant 1381 1378 caches do not observe the max-age directive. 1382 1379 </p> 1383 <p id="rfc.section. 3.2.3.p.6">Other directives allow a user agent to modify the basic expiration mechanism. These directives <em class="bcp14">MAY</em> be specified on a request:1384 </p> 1385 <p id="rfc.section. 3.2.3.p.7"> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.1"></span> max-age1380 <p id="rfc.section.15.2.3.p.6">Other directives allow a user agent to modify the basic expiration mechanism. These directives <em class="bcp14">MAY</em> be specified on a request: 1381 </p> 1382 <p id="rfc.section.15.2.3.p.7"> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.1"></span> max-age 1386 1383 </p> 1387 1384 <dl class="empty"> … … 1390 1387 </dd> 1391 1388 </dl> 1392 <p id="rfc.section. 3.2.3.p.8"> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.m.2"></span> min-fresh1389 <p id="rfc.section.15.2.3.p.8"> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.m.2"></span> min-fresh 1393 1390 </p> 1394 1391 <dl class="empty"> … … 1398 1395 </dd> 1399 1396 </dl> 1400 <p id="rfc.section. 3.2.3.p.9"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.m.3"></span> max-stale1397 <p id="rfc.section.15.2.3.p.9"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.m.3"></span> max-stale 1401 1398 </p> 1402 1399 <dl class="empty"> … … 1406 1403 </dd> 1407 1404 </dl> 1408 <p id="rfc.section. 3.2.3.p.10">If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured1405 <p id="rfc.section.15.2.3.p.10">If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured 1409 1406 to override the expiration time of a response, the cache <em class="bcp14">MUST</em> attach a Warning header to the stale response, using Warning 110 (Response is stale). 1410 1407 </p> 1411 <p id="rfc.section. 3.2.3.p.11">A cache <em class="bcp14">MAY</em> be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements1408 <p id="rfc.section.15.2.3.p.11">A cache <em class="bcp14">MAY</em> be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements 1412 1409 concerning cache validation (e.g., a "must-revalidate" cache-control directive). 1413 1410 </p> 1414 <p id="rfc.section. 3.2.3.p.12">If both the new request and the cached entry include "max-age" directives, then the lesser of the two values is used for determining1411 <p id="rfc.section.15.2.3.p.12">If both the new request and the cached entry include "max-age" directives, then the lesser of the two values is used for determining 1415 1412 the freshness of the cached entry for that request. 1416 1413 </p> 1417 <h3 id="rfc.section. 3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="cache.revalidation.and.reload.controls" href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></h3>1418 <p id="rfc.section. 3.2.4.p.1">Sometimes a user agent might want or need to insist that a cache revalidate its cache entry with the origin server (and not1414 <h3 id="rfc.section.15.2.4"><a href="#rfc.section.15.2.4">15.2.4</a> <a id="cache.revalidation.and.reload.controls" href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></h3> 1415 <p id="rfc.section.15.2.4.p.1">Sometimes a user agent might want or need to insist that a cache revalidate its cache entry with the origin server (and not 1419 1416 just with the next cache along the path to the origin server), or to reload its cache entry from the origin server. End-to-end 1420 1417 revalidation might be necessary if either the cache or the origin server has overestimated the expiration time of the cached 1421 1418 response. End-to-end reload may be necessary if the cache entry has become corrupted for some reason. 1422 1419 </p> 1423 <p id="rfc.section. 3.2.4.p.2">End-to-end revalidation may be requested either when the client does not have its own local cached copy, in which case we1420 <p id="rfc.section.15.2.4.p.2">End-to-end revalidation may be requested either when the client does not have its own local cached copy, in which case we 1424 1421 call it "unspecified end-to-end revalidation", or when the client does have a local cached copy, in which case we call it 1425 1422 "specific end-to-end revalidation." 1426 1423 </p> 1427 <p id="rfc.section. 3.2.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p>1428 <p id="rfc.section. 3.2.4.p.4">End-to-end reload </p>1424 <p id="rfc.section.15.2.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p> 1425 <p id="rfc.section.15.2.4.p.4">End-to-end reload </p> 1429 1426 <dl class="empty"> 1430 1427 <dd>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". … … 1432 1429 </dd> 1433 1430 </dl> 1434 <p id="rfc.section. 3.2.4.p.5">Specific end-to-end revalidation </p>1431 <p id="rfc.section.15.2.4.p.5">Specific end-to-end revalidation </p> 1435 1432 <dl class="empty"> 1436 1433 <dd>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to … … 1439 1436 </dd> 1440 1437 </dl> 1441 <p id="rfc.section. 3.2.4.p.6">Unspecified end-to-end revalidation </p>1438 <p id="rfc.section.15.2.4.p.6">Unspecified end-to-end revalidation </p> 1442 1439 <dl class="empty"> 1443 1440 <dd>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate … … 1447 1444 </dd> 1448 1445 </dl> 1449 <p id="rfc.section. 3.2.4.p.7"> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.m.4"></span> max-age1446 <p id="rfc.section.15.2.4.p.7"> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.m.4"></span> max-age 1450 1447 </p> 1451 1448 <dl class="empty"> … … 1464 1461 </dd> 1465 1462 </dl> 1466 <p id="rfc.section. 3.2.4.p.8"> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.o.1"></span> only-if-cached1463 <p id="rfc.section.15.2.4.p.8"> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.o.1"></span> only-if-cached 1467 1464 </p> 1468 1465 <dl class="empty"> … … 1474 1471 </dd> 1475 1472 </dl> 1476 <p id="rfc.section. 3.2.4.p.9"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.m.5"></span> must-revalidate1473 <p id="rfc.section.15.2.4.p.9"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.m.5"></span> must-revalidate 1477 1474 </p> 1478 1475 <dl class="empty"> … … 1492 1489 </dd> 1493 1490 </dl> 1494 <p id="rfc.section. 3.2.4.p.10"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.3"></span> proxy-revalidate1491 <p id="rfc.section.15.2.4.p.10"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.3"></span> proxy-revalidate 1495 1492 </p> 1496 1493 <dl class="empty"> … … 1503 1500 </dd> 1504 1501 </dl> 1505 <h3 id="rfc.section. 3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="no-transform.directive" href="#no-transform.directive">No-Transform Directive</a></h3>1506 <p id="rfc.section. 3.2.5.p.1"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.3"></span> no-transform1502 <h3 id="rfc.section.15.2.5"><a href="#rfc.section.15.2.5">15.2.5</a> <a id="no-transform.directive" href="#no-transform.directive">No-Transform Directive</a></h3> 1503 <p id="rfc.section.15.2.5.p.1"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.3"></span> no-transform 1507 1504 </p> 1508 1505 <dl class="empty"> … … 1515 1512 authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body. 1516 1513 </dd> 1517 <dd>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 2.5.2</a> as being subject to the no-transform directive. This implies that the cache or proxy <em class="bcp14">MUST NOT</em> change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself.1518 </dd> 1519 </dl> 1520 <h3 id="rfc.section. 3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>1521 <p id="rfc.section. 3.2.6.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional1514 <dd>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 6.2</a> as being subject to the no-transform directive. This implies that the cache or proxy <em class="bcp14">MUST NOT</em> change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself. 1515 </dd> 1516 </dl> 1517 <h3 id="rfc.section.15.2.6"><a href="#rfc.section.15.2.6">15.2.6</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> 1518 <p id="rfc.section.15.2.6.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional 1522 1519 assigned value. Informational extensions (those which do not require a change in cache behavior) <em class="bcp14">MAY</em> be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers 1523 1520 to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications … … 1526 1523 way, extensions to the cache-control directives can be made without requiring changes to the base protocol. 1527 1524 </p> 1528 <p id="rfc.section. 3.2.6.p.2">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,1525 <p id="rfc.section.15.2.6.p.2">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version, 1529 1526 obeying certain extensions, and ignoring all directives that it does not understand. 1530 1527 </p> 1531 <p id="rfc.section. 3.2.6.p.3">For example, consider a hypothetical new response directive called community which acts as a modifier to the private directive.1528 <p id="rfc.section.15.2.6.p.3">For example, consider a hypothetical new response directive called community which acts as a modifier to the private directive. 1532 1529 We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members 1533 1530 of the community named within its value may cache the response. An origin server wishing to allow the UCI community to use … … 1535 1532 </p> 1536 1533 <div id="rfc.figure.u.12"></div><pre class="text"> Cache-Control: private, community="UCI" 1537 </pre><p id="rfc.section. 3.2.6.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since1534 </pre><p id="rfc.section.15.2.6.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since 1538 1535 it will also see and understand the private directive and thus default to the safe behavior. 1539 1536 </p> 1540 <p id="rfc.section. 3.2.6.p.6">Unrecognized cache-directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache-directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard1537 <p id="rfc.section.15.2.6.p.6">Unrecognized cache-directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache-directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard 1541 1538 directives (or the response's default cacheability) such that the cache behavior will remain minimally correct even if the 1542 1539 cache does not understand the extension(s). … … 1544 1541 <div id="rfc.iref.e.2"></div> 1545 1542 <div id="rfc.iref.h.4"></div> 1546 <h2 id="rfc.section. 3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2>1547 <p id="rfc.section. 3.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may1543 <h2 id="rfc.section.15.3"><a href="#rfc.section.15.3">15.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2> 1544 <p id="rfc.section.15.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may 1548 1545 not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin 1549 server (or with an intermediate cache that has a fresh copy of the entity). See <a href="#expiration.model" title="Expiration Model">Section 2.2</a> for further discussion of the expiration model.1550 </p> 1551 <p id="rfc.section. 3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after1546 server (or with an intermediate cache that has a fresh copy of the entity). See <a href="#expiration.model" title="Expiration Model">Section 3</a> for further discussion of the expiration model. 1547 </p> 1548 <p id="rfc.section.15.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 1552 1549 that time. 1553 1550 </p> 1554 <p id="rfc.section. 3.3.p.3">The format is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.1551 <p id="rfc.section.15.3.p.3">The format is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1555 1552 </p> 1556 1553 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Expires = "Expires" ":" HTTP-date 1557 </pre><p id="rfc.section. 3.3.p.5">An example of its use is</p>1554 </pre><p id="rfc.section.15.3.p.5">An example of its use is</p> 1558 1555 <div id="rfc.figure.u.14"></div><pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1559 </pre><p id="rfc.section. 3.3.p.7"> </p>1560 <dl class="empty"> 1561 <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>), that directive overrides the Expires field.1562 </dd> 1563 </dl> 1564 <p id="rfc.section. 3.3.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").1565 </p> 1566 <p id="rfc.section. 3.3.p.9">To mark a response as "already expired," an origin server sends an Expires date that is equal to the Date header value. (See1567 the rules for expiration calculations in <a href="#expiration.calculations" title="Expiration Calculations">Section 2.2.4</a>.)1568 </p> 1569 <p id="rfc.section. 3.3.p.10">To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response1556 </pre><p id="rfc.section.15.3.p.7"> </p> 1557 <dl class="empty"> 1558 <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a>), that directive overrides the Expires field. 1559 </dd> 1560 </dl> 1561 <p id="rfc.section.15.3.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 1562 </p> 1563 <p id="rfc.section.15.3.p.9">To mark a response as "already expired," an origin server sends an Expires date that is equal to the Date header value. (See 1564 the rules for expiration calculations in <a href="#expiration.calculations" title="Expiration Calculations">Section 3.4</a>.) 1565 </p> 1566 <p id="rfc.section.15.3.p.10">To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response 1570 1567 is sent. HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future. 1571 1568 </p> 1572 <p id="rfc.section. 3.3.p.11">The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by1569 <p id="rfc.section.15.3.p.11">The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by 1573 1570 default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field 1574 (<a href="#header.cache-control" id="rfc.xref.header.cache-control.9" title="Cache-Control">Section 3.2</a>).1571 (<a href="#header.cache-control" id="rfc.xref.header.cache-control.9" title="Cache-Control">Section 15.2</a>). 1575 1572 </p> 1576 1573 <div id="rfc.iref.p.4"></div> 1577 1574 <div id="rfc.iref.h.5"></div> 1578 <h2 id="rfc.section. 3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2>1579 <p id="rfc.section. 3.4.p.1">The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along1575 <h2 id="rfc.section.15.4"><a href="#rfc.section.15.4">15.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> 1576 <p id="rfc.section.15.4.p.1">The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along 1580 1577 the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some 1581 1578 systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives. … … 1584 1581 pragma-directive = "no-cache" | extension-pragma 1585 1582 extension-pragma = token [ "=" ( token | quoted-string ) ] 1586 </pre><p id="rfc.section. 3.4.p.3">When the no-cache directive is present in a request message, an application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive1587 has the same semantics as the no-cache cache-directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.10" title="Cache-Control">Section 3.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant.1588 </p> 1589 <p id="rfc.section. 3.4.p.4">Pragma directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives1583 </pre><p id="rfc.section.15.4.p.3">When the no-cache directive is present in a request message, an application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive 1584 has the same semantics as the no-cache cache-directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.10" title="Cache-Control">Section 15.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. 1585 </p> 1586 <p id="rfc.section.15.4.p.4">Pragma directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives 1590 1587 might be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific 1591 1588 recipient; however, any pragma directive not relevant to a recipient <em class="bcp14">SHOULD</em> be ignored by that recipient. 1592 1589 </p> 1593 <p id="rfc.section. 3.4.p.5">HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in1590 <p id="rfc.section.15.4.p.5">HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in 1594 1591 HTTP. 1595 1592 </p> … … 1601 1598 <div id="rfc.iref.v.2"></div> 1602 1599 <div id="rfc.iref.h.6"></div> 1603 <h2 id="rfc.section. 3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2>1604 <p id="rfc.section. 3.5.p.1">The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether1600 <h2 id="rfc.section.15.5"><a href="#rfc.section.15.5">15.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> 1601 <p id="rfc.section.15.5.p.1">The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether 1605 1602 a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, 1606 1603 the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value 1607 1604 of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the 1608 appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> for use of the Vary header field by caches.1605 appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 7</a> for use of the Vary header field by caches. 1609 1606 </p> 1610 1607 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.13"></span> Vary = "Vary" ":" ( "*" | 1#field-name ) 1611 </pre><p id="rfc.section. 3.5.p.3">An HTTP/1.1 server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache1608 </pre><p id="rfc.section.15.5.p.3">An HTTP/1.1 server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache 1612 1609 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that 1613 1610 resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide 1614 1611 the user agent with useful information about the dimensions over which the response varies at the time of the response. 1615 1612 </p> 1616 <p id="rfc.section. 3.5.p.4">A Vary field value consisting of a list of field-names signals that the representation selected for the response is based1613 <p id="rfc.section.15.5.p.4">A Vary field value consisting of a list of field-names signals that the representation selected for the response is based 1617 1614 on a selection algorithm which considers ONLY the listed request-header field values in selecting the most appropriate representation. 1618 1615 A cache <em class="bcp14">MAY</em> assume that the same selection will be made for future requests with the same values for the listed field names, for the duration 1619 1616 of time for which the response is fresh. 1620 1617 </p> 1621 <p id="rfc.section. 3.5.p.5">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names1618 <p id="rfc.section.15.5.p.5">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names 1622 1619 are case-insensitive. 1623 1620 </p> 1624 <p id="rfc.section. 3.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address1621 <p id="rfc.section.15.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address 1625 1622 of the client), play a role in the selection of the response representation. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server. 1626 1623 </p> 1627 1624 <div id="rfc.iref.w.1"></div> 1628 1625 <div id="rfc.iref.h.7"></div> 1629 <h2 id="rfc.section. 3.6"><a href="#rfc.section.3.6">3.6</a> <a id="header.warning" href="#header.warning">Warning</a></h2>1630 <p id="rfc.section. 3.6.p.1">The Warning general-header field is used to carry additional information about the status or transformation of a message which1626 <h2 id="rfc.section.15.6"><a href="#rfc.section.15.6">15.6</a> <a id="header.warning" href="#header.warning">Warning</a></h2> 1627 <p id="rfc.section.15.6.p.1">The Warning general-header field is used to carry additional information about the status or transformation of a message which 1631 1628 might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency 1632 1629 from caching operations or transformations applied to the entity body of the message. 1633 1630 </p> 1634 <p id="rfc.section. 3.6.p.2">Warning headers are sent with responses using:</p>1631 <p id="rfc.section.15.6.p.2">Warning headers are sent with responses using:</p> 1635 1632 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> Warning = "Warning" ":" 1#warning-value 1636 1633 … … 1644 1641 warn-text = quoted-string 1645 1642 warn-date = DQUOTE HTTP-date DQUOTE 1646 </pre><p id="rfc.section. 3.6.p.4">A response <em class="bcp14">MAY</em> carry more than one Warning header.1647 </p> 1648 <p id="rfc.section. 3.6.p.5">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response.1643 </pre><p id="rfc.section.15.6.p.4">A response <em class="bcp14">MAY</em> carry more than one Warning header. 1644 </p> 1645 <p id="rfc.section.15.6.p.5">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. 1649 1646 This decision <em class="bcp14">MAY</em> be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the 1650 1647 Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). 1651 1648 </p> 1652 <p id="rfc.section. 3.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.1653 </p> 1654 <p id="rfc.section. 3.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can1649 <p id="rfc.section.15.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>. 1650 </p> 1651 <p id="rfc.section.15.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can 1655 1652 only be applied to response messages. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers. A cache <em class="bcp14">MUST NOT</em> delete any Warning header that it received with a message. However, if a cache successfully validates a cache entry, it <em class="bcp14">SHOULD</em> remove any Warning headers previously attached to that entry except as specified for specific Warning codes. It <em class="bcp14">MUST</em> then add any Warning headers received in the validating response. In other words, Warning headers are those that would be 1656 1653 attached to the most recent relevant response. 1657 1654 </p> 1658 <p id="rfc.section. 3.6.p.8">When multiple Warning headers are attached to a response, the user agent ought to inform the user of as many of them as possible,1655 <p id="rfc.section.15.6.p.8">When multiple Warning headers are attached to a response, the user agent ought to inform the user of as many of them as possible, 1659 1656 in the order that they appear in the response. If it is not possible to inform the user of all of the warnings, the user agent <em class="bcp14">SHOULD</em> follow these heuristics: 1660 1657 </p> … … 1665 1662 </li> 1666 1663 </ul> 1667 <p id="rfc.section. 3.6.p.9">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind.1668 </p> 1669 <p id="rfc.section. 3.6.p.10">Requirements for the behavior of caches with respect to Warnings are stated in <a href="#warnings" title="Warnings">Section 2.1.2</a>.1670 </p> 1671 <p id="rfc.section. 3.6.p.11">This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its1664 <p id="rfc.section.15.6.p.9">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. 1665 </p> 1666 <p id="rfc.section.15.6.p.10">Requirements for the behavior of caches with respect to Warnings are stated in <a href="#warnings" title="Warnings">Section 2.2</a>. 1667 </p> 1668 <p id="rfc.section.15.6.p.11">This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its 1672 1669 meaning. 1673 1670 </p> 1674 <p id="rfc.section. 3.6.p.12">110 Response is stale </p>1671 <p id="rfc.section.15.6.p.12">110 Response is stale </p> 1675 1672 <dl class="empty"> 1676 1673 <dd> <em class="bcp14">MUST</em> be included whenever the returned response is stale. 1677 1674 </dd> 1678 1675 </dl> 1679 <p id="rfc.section. 3.6.p.13">111 Revalidation failed </p>1676 <p id="rfc.section.15.6.p.13">111 Revalidation failed </p> 1680 1677 <dl class="empty"> 1681 1678 <dd> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability … … 1683 1680 </dd> 1684 1681 </dl> 1685 <p id="rfc.section. 3.6.p.14">112 Disconnected operation </p>1682 <p id="rfc.section.15.6.p.14">112 Disconnected operation </p> 1686 1683 <dl class="empty"> 1687 1684 <dd> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time. 1688 1685 </dd> 1689 1686 </dl> 1690 <p id="rfc.section. 3.6.p.15">113 Heuristic expiration </p>1687 <p id="rfc.section.15.6.p.15">113 Heuristic expiration </p> 1691 1688 <dl class="empty"> 1692 1689 <dd> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater … … 1694 1691 </dd> 1695 1692 </dl> 1696 <p id="rfc.section. 3.6.p.16">199 Miscellaneous warning </p>1693 <p id="rfc.section.15.6.p.16">199 Miscellaneous warning </p> 1697 1694 <dl class="empty"> 1698 1695 <dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user. 1699 1696 </dd> 1700 1697 </dl> 1701 <p id="rfc.section. 3.6.p.17">214 Transformation applied </p>1698 <p id="rfc.section.15.6.p.17">214 Transformation applied </p> 1702 1699 <dl class="empty"> 1703 1700 <dd> <em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the … … 1706 1703 </dd> 1707 1704 </dl> 1708 <p id="rfc.section. 3.6.p.18">299 Miscellaneous persistent warning </p>1705 <p id="rfc.section.15.6.p.18">299 Miscellaneous persistent warning </p> 1709 1706 <dl class="empty"> 1710 1707 <dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action. 1711 1708 </dd> 1712 1709 </dl> 1713 <p id="rfc.section. 3.6.p.19">If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the date in the response.1714 </p> 1715 <p id="rfc.section. 3.6.p.20">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from1710 <p id="rfc.section.15.6.p.19">If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the date in the response. 1711 </p> 1712 <p id="rfc.section.15.6.p.20">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from 1716 1713 the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning 1717 1714 header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well. 1718 1715 </p> 1719 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>1720 <p id="rfc.section. 4.p.1">TBD.</p>1721 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1722 <p id="rfc.section. 5.p.1">Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target1716 <h1 id="rfc.section.16"><a href="#rfc.section.16">16.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1717 <p id="rfc.section.16.p.1">TBD.</p> 1718 <h1 id="rfc.section.17"><a href="#rfc.section.17">17.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1719 <p id="rfc.section.17.p.1">Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target 1723 1720 for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal 1724 1721 information long after a user believes that the information has been removed from the network. Therefore, cache contents should 1725 1722 be protected as sensitive information. 1726 1723 </p> 1727 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>1728 <p id="rfc.section. 6.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including:1724 <h1 id="rfc.section.18"><a href="#rfc.section.18">18.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1725 <p id="rfc.section.18.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including: 1729 1726 Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter. 1730 1727 </p> 1731 <h1 id="rfc.references"><a id="rfc.section. 7" href="#rfc.section.7">7.</a> References1728 <h1 id="rfc.references"><a id="rfc.section.19" href="#rfc.section.19">19.</a> References 1732 1729 </h1> 1733 <h2 id="rfc.references.1"><a href="#rfc.section. 7.1" id="rfc.section.7.1">7.1</a> Normative References1730 <h2 id="rfc.references.1"><a href="#rfc.section.19.1" id="rfc.section.19.1">19.1</a> Normative References 1734 1731 </h2> 1735 1732 <table summary="Normative References"> … … 1782 1779 </tr> 1783 1780 </table> 1784 <h2 id="rfc.references.2"><a href="#rfc.section. 7.2" id="rfc.section.7.2">7.2</a> Informative References1781 <h2 id="rfc.references.2"><a href="#rfc.section.19.2" id="rfc.section.19.2">19.2</a> Informative References 1785 1782 </h2> 1786 1783 <table summary="Informative References"> … … 1814 1811 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1815 1812 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> 1816 <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability"> 2.4</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.11" title="Cache-Control">3.2</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">3.2.3</a>)1813 <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">5</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.11" title="Cache-Control">15.2</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">15.2.3</a>) 1817 1814 </p> 1818 1815 <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1819 1816 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1820 computed. (<a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 2.5.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)1821 </p> 1822 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. (<a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 2.5.2</a>)1817 computed. (<a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 6.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) 1818 </p> 1819 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. (<a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 6.2</a>) 1823 1820 </p> 1824 1821 <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send 1825 needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Headers">Section 2.5.3</a>)1826 </p> 1827 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 3.2.3</a>)1828 </p> 1829 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#warnings" title="Warnings">2. 1.2</a>, <a href="#expiration.calculations" title="Expiration Calculations">2.2.4</a>, <a href="#non-modifiable.headers" title="Non-modifiable Headers">2.5.2</a>, <a href="#combining.headers" title="Combining Headers">2.5.3</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">3.2.3</a>, and <a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.1822 needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Headers">Section 6.3</a>) 1823 </p> 1824 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 15.2.3</a>) 1825 </p> 1826 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#warnings" title="Warnings">2.2</a>, <a href="#expiration.calculations" title="Expiration Calculations">3.4</a>, <a href="#non-modifiable.headers" title="Non-modifiable Headers">6.2</a>, <a href="#combining.headers" title="Combining Headers">6.3</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">15.2.3</a>, and <a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">15.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 1830 1827 </p> 1831 1828 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1832 <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Invalidation After Updates or Deletions">Section 2.10</a>)1829 <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Invalidation After Updates or Deletions">Section 11</a>) 1833 1830 </p> 1834 1831 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) … … 1836 1833 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 1837 1834 </h2> 1838 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.1835 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1839 1836 </p> 1840 1837 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p6-cache-00 … … 1900 1897 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 1901 1898 <li class="indline1">age <a class="iref" href="#rfc.iref.a.1">1.2</a></li> 1902 <li class="indline1">Age header <a class="iref" href="#rfc.iref.a.2"><b> 3.1</b></a></li>1899 <li class="indline1">Age header <a class="iref" href="#rfc.iref.a.2"><b>15.1</b></a></li> 1903 1900 </ul> 1904 1901 </li> 1905 1902 <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"> 1906 <li class="indline1">cache <a class="iref" href="#rfc.iref.c.1">1. 2</a></li>1903 <li class="indline1">cache <a class="iref" href="#rfc.iref.c.1">1.1</a></li> 1907 1904 <li class="indline1">Cache Directives 1908 1905 <ul class="ind"> 1909 <li class="indline1">max-age <a class="iref" href="#rfc.iref.c.9"><b> 3.2.3</b></a>, <a class="iref" href="#rfc.iref.c.12"><b>3.2.4</b></a></li>1910 <li class="indline1">max-stale <a class="iref" href="#rfc.iref.c.11"><b> 3.2.3</b></a></li>1911 <li class="indline1">min-fresh <a class="iref" href="#rfc.iref.c.10"><b> 3.2.3</b></a></li>1912 <li class="indline1">must-revalidate <a class="iref" href="#rfc.iref.c.14"><b> 3.2.4</b></a></li>1913 <li class="indline1">no-cache <a class="iref" href="#rfc.iref.c.6"><b> 3.2.1</b></a></li>1914 <li class="indline1">no-store <a class="iref" href="#rfc.iref.c.7"><b> 3.2.2</b></a></li>1915 <li class="indline1">no-transform <a class="iref" href="#rfc.iref.c.16"><b> 3.2.5</b></a></li>1916 <li class="indline1">only-if-cached <a class="iref" href="#rfc.iref.c.13"><b> 3.2.4</b></a></li>1917 <li class="indline1">private <a class="iref" href="#rfc.iref.c.5"><b> 3.2.1</b></a></li>1918 <li class="indline1">proxy-revalidate <a class="iref" href="#rfc.iref.c.15"><b> 3.2.4</b></a></li>1919 <li class="indline1">public <a class="iref" href="#rfc.iref.c.4"><b> 3.2.1</b></a></li>1920 <li class="indline1">s-maxage <a class="iref" href="#rfc.iref.c.8"><b> 3.2.3</b></a></li>1906 <li class="indline1">max-age <a class="iref" href="#rfc.iref.c.9"><b>15.2.3</b></a>, <a class="iref" href="#rfc.iref.c.12"><b>15.2.4</b></a></li> 1907 <li class="indline1">max-stale <a class="iref" href="#rfc.iref.c.11"><b>15.2.3</b></a></li> 1908 <li class="indline1">min-fresh <a class="iref" href="#rfc.iref.c.10"><b>15.2.3</b></a></li> 1909 <li class="indline1">must-revalidate <a class="iref" href="#rfc.iref.c.14"><b>15.2.4</b></a></li> 1910 <li class="indline1">no-cache <a class="iref" href="#rfc.iref.c.6"><b>15.2.1</b></a></li> 1911 <li class="indline1">no-store <a class="iref" href="#rfc.iref.c.7"><b>15.2.2</b></a></li> 1912 <li class="indline1">no-transform <a class="iref" href="#rfc.iref.c.16"><b>15.2.5</b></a></li> 1913 <li class="indline1">only-if-cached <a class="iref" href="#rfc.iref.c.13"><b>15.2.4</b></a></li> 1914 <li class="indline1">private <a class="iref" href="#rfc.iref.c.5"><b>15.2.1</b></a></li> 1915 <li class="indline1">proxy-revalidate <a class="iref" href="#rfc.iref.c.15"><b>15.2.4</b></a></li> 1916 <li class="indline1">public <a class="iref" href="#rfc.iref.c.4"><b>15.2.1</b></a></li> 1917 <li class="indline1">s-maxage <a class="iref" href="#rfc.iref.c.8"><b>15.2.3</b></a></li> 1921 1918 </ul> 1922 1919 </li> 1923 <li class="indline1">Cache-Control header <a class="iref" href="#rfc.xref.header.cache-control.1">2.1 .1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.1.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">2.2.5</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">2.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">2.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">2.8</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.9">3.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.10">3.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.11">A.1</a></li>1920 <li class="indline1">Cache-Control header <a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">3.5</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">5</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">5</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">9</a>, <a class="iref" href="#rfc.iref.c.3"><b>15.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.9">15.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.10">15.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.11">A.1</a></li> 1924 1921 <li class="indline1">cacheable <a class="iref" href="#rfc.iref.c.2">1.2</a></li> 1925 1922 </ul> 1926 1923 </li> 1927 1924 <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"> 1928 <li class="indline1">Expires header <a class="iref" href="#rfc.xref.header.expires.1"> 2.4</a>, <a class="iref" href="#rfc.xref.header.expires.2">3.2.3</a>, <a class="iref" href="#rfc.iref.e.2"><b>3.3</b></a></li>1925 <li class="indline1">Expires header <a class="iref" href="#rfc.xref.header.expires.1">5</a>, <a class="iref" href="#rfc.xref.header.expires.2">15.2.3</a>, <a class="iref" href="#rfc.iref.e.2"><b>15.3</b></a></li> 1929 1926 <li class="indline1">explicit expiration time <a class="iref" href="#rfc.iref.e.1">1.2</a></li> 1930 1927 </ul> … … 1939 1936 <li class="indline1"><tt>Grammar</tt> 1940 1937 <ul class="ind"> 1941 <li class="indline1"><tt>Age</tt> <a class="iref" href="#rfc.iref.g. 2"><b>3.1</b></a></li>1942 <li class="indline1"><tt>age-value</tt> <a class="iref" href="#rfc.iref.g. 3"><b>3.1</b></a></li>1943 <li class="indline1"><tt>Cache-Control</tt> <a class="iref" href="#rfc.iref.g.4"><b> 3.2</b></a></li>1944 <li class="indline1"><tt>cache-directive</tt> <a class="iref" href="#rfc.iref.g.5"><b> 3.2</b></a></li>1945 <li class="indline1"><tt>cache-extension</tt> <a class="iref" href="#rfc.iref.g.8"><b> 3.2</b></a></li>1946 <li class="indline1"><tt>cache-request-directive</tt> <a class="iref" href="#rfc.iref.g.6"><b> 3.2</b></a></li>1947 <li class="indline1"><tt>cache-response-directive</tt> <a class="iref" href="#rfc.iref.g.7"><b> 3.2</b></a></li>1948 <li class="indline1"><tt>delta-seconds</tt> <a class="iref" href="#rfc.iref.g. 1"><b>1.3</b></a></li>1949 <li class="indline1"><tt>Expires</tt> <a class="iref" href="#rfc.iref.g.9"><b> 3.3</b></a></li>1950 <li class="indline1"><tt>extension-pragma</tt> <a class="iref" href="#rfc.iref.g.12"><b> 3.4</b></a></li>1951 <li class="indline1"><tt>Pragma</tt> <a class="iref" href="#rfc.iref.g.10"><b> 3.4</b></a></li>1952 <li class="indline1"><tt>pragma-directive</tt> <a class="iref" href="#rfc.iref.g.11"><b> 3.4</b></a></li>1953 <li class="indline1"><tt>Vary</tt> <a class="iref" href="#rfc.iref.g.13"><b> 3.5</b></a></li>1954 <li class="indline1"><tt>warn-agent</tt> <a class="iref" href="#rfc.iref.g.17"><b> 3.6</b></a></li>1955 <li class="indline1"><tt>warn-code</tt> <a class="iref" href="#rfc.iref.g.16"><b> 3.6</b></a></li>1956 <li class="indline1"><tt>warn-date</tt> <a class="iref" href="#rfc.iref.g.19"><b> 3.6</b></a></li>1957 <li class="indline1"><tt>warn-text</tt> <a class="iref" href="#rfc.iref.g.18"><b> 3.6</b></a></li>1958 <li class="indline1"><tt>Warning</tt> <a class="iref" href="#rfc.iref.g.14"><b> 3.6</b></a></li>1959 <li class="indline1"><tt>warning-value</tt> <a class="iref" href="#rfc.iref.g.15"><b> 3.6</b></a></li>1938 <li class="indline1"><tt>Age</tt> <a class="iref" href="#rfc.iref.g.1"><b>15.1</b></a></li> 1939 <li class="indline1"><tt>age-value</tt> <a class="iref" href="#rfc.iref.g.2"><b>15.1</b></a></li> 1940 <li class="indline1"><tt>Cache-Control</tt> <a class="iref" href="#rfc.iref.g.4"><b>15.2</b></a></li> 1941 <li class="indline1"><tt>cache-directive</tt> <a class="iref" href="#rfc.iref.g.5"><b>15.2</b></a></li> 1942 <li class="indline1"><tt>cache-extension</tt> <a class="iref" href="#rfc.iref.g.8"><b>15.2</b></a></li> 1943 <li class="indline1"><tt>cache-request-directive</tt> <a class="iref" href="#rfc.iref.g.6"><b>15.2</b></a></li> 1944 <li class="indline1"><tt>cache-response-directive</tt> <a class="iref" href="#rfc.iref.g.7"><b>15.2</b></a></li> 1945 <li class="indline1"><tt>delta-seconds</tt> <a class="iref" href="#rfc.iref.g.3"><b>15.1</b></a></li> 1946 <li class="indline1"><tt>Expires</tt> <a class="iref" href="#rfc.iref.g.9"><b>15.3</b></a></li> 1947 <li class="indline1"><tt>extension-pragma</tt> <a class="iref" href="#rfc.iref.g.12"><b>15.4</b></a></li> 1948 <li class="indline1"><tt>Pragma</tt> <a class="iref" href="#rfc.iref.g.10"><b>15.4</b></a></li> 1949 <li class="indline1"><tt>pragma-directive</tt> <a class="iref" href="#rfc.iref.g.11"><b>15.4</b></a></li> 1950 <li class="indline1"><tt>Vary</tt> <a class="iref" href="#rfc.iref.g.13"><b>15.5</b></a></li> 1951 <li class="indline1"><tt>warn-agent</tt> <a class="iref" href="#rfc.iref.g.17"><b>15.6</b></a></li> 1952 <li class="indline1"><tt>warn-code</tt> <a class="iref" href="#rfc.iref.g.16"><b>15.6</b></a></li> 1953 <li class="indline1"><tt>warn-date</tt> <a class="iref" href="#rfc.iref.g.19"><b>15.6</b></a></li> 1954 <li class="indline1"><tt>warn-text</tt> <a class="iref" href="#rfc.iref.g.18"><b>15.6</b></a></li> 1955 <li class="indline1"><tt>Warning</tt> <a class="iref" href="#rfc.iref.g.14"><b>15.6</b></a></li> 1956 <li class="indline1"><tt>warning-value</tt> <a class="iref" href="#rfc.iref.g.15"><b>15.6</b></a></li> 1960 1957 </ul> 1961 1958 </li> … … 1965 1962 <li class="indline1">Headers 1966 1963 <ul class="ind"> 1967 <li class="indline1">Age <a class="iref" href="#rfc.iref.h.2"><b> 3.1</b></a></li>1968 <li class="indline1">Cache-Control <a class="iref" href="#rfc.xref.header.cache-control.1">2.1 .1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.1.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">2.2.5</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">2.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">2.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">2.8</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.9">3.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.10">3.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.11">A.1</a></li>1969 <li class="indline1">Expires <a class="iref" href="#rfc.xref.header.expires.1"> 2.4</a>, <a class="iref" href="#rfc.xref.header.expires.2">3.2.3</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.3</b></a></li>1970 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1"> 3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a></li>1971 <li class="indline1">Vary <a class="iref" href="#rfc.xref.header.vary.1"> 2.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a></li>1972 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">2.1 .1</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.1.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.1.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">2.5.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">2.5.3</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li>1964 <li class="indline1">Age <a class="iref" href="#rfc.iref.h.2"><b>15.1</b></a></li> 1965 <li class="indline1">Cache-Control <a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">3.5</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">5</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">5</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">9</a>, <a class="iref" href="#rfc.iref.h.3"><b>15.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.9">15.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.10">15.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.11">A.1</a></li> 1966 <li class="indline1">Expires <a class="iref" href="#rfc.xref.header.expires.1">5</a>, <a class="iref" href="#rfc.xref.header.expires.2">15.2.3</a>, <a class="iref" href="#rfc.iref.h.4"><b>15.3</b></a></li> 1967 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1">15.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>15.4</b></a></li> 1968 <li class="indline1">Vary <a class="iref" href="#rfc.xref.header.vary.1">7</a>, <a class="iref" href="#rfc.iref.h.6"><b>15.5</b></a></li> 1969 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">2.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">6.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">6.3</a>, <a class="iref" href="#rfc.iref.h.7"><b>15.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li> 1973 1970 </ul> 1974 1971 </li> … … 1977 1974 </li> 1978 1975 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 1979 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1"> 3.6</a>, <a class="iref" href="#ISO-8859-1"><b>7.1</b></a></li>1976 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">15.6</a>, <a class="iref" href="#ISO-8859-1"><b>19.1</b></a></li> 1980 1977 </ul> 1981 1978 </li> … … 1983 1980 <li class="indline1">max-age 1984 1981 <ul class="ind"> 1985 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.1"><b> 3.2.3</b></a>, <a class="iref" href="#rfc.iref.m.4"><b>3.2.4</b></a></li>1982 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.1"><b>15.2.3</b></a>, <a class="iref" href="#rfc.iref.m.4"><b>15.2.4</b></a></li> 1986 1983 </ul> 1987 1984 </li> 1988 1985 <li class="indline1">max-stale 1989 1986 <ul class="ind"> 1990 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.3"><b> 3.2.3</b></a></li>1987 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.3"><b>15.2.3</b></a></li> 1991 1988 </ul> 1992 1989 </li> 1993 1990 <li class="indline1">min-fresh 1994 1991 <ul class="ind"> 1995 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.2"><b> 3.2.3</b></a></li>1992 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.2"><b>15.2.3</b></a></li> 1996 1993 </ul> 1997 1994 </li> 1998 1995 <li class="indline1">must-revalidate 1999 1996 <ul class="ind"> 2000 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.5"><b> 3.2.4</b></a></li>1997 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.5"><b>15.2.4</b></a></li> 2001 1998 </ul> 2002 1999 </li> … … 2006 2003 <li class="indline1">no-cache 2007 2004 <ul class="ind"> 2008 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.1"><b> 3.2.1</b></a></li>2005 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.1"><b>15.2.1</b></a></li> 2009 2006 </ul> 2010 2007 </li> 2011 2008 <li class="indline1">no-store 2012 2009 <ul class="ind"> 2013 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.2"><b> 3.2.2</b></a></li>2010 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.2"><b>15.2.2</b></a></li> 2014 2011 </ul> 2015 2012 </li> 2016 2013 <li class="indline1">no-transform 2017 2014 <ul class="ind"> 2018 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.3"><b> 3.2.5</b></a></li>2015 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.3"><b>15.2.5</b></a></li> 2019 2016 </ul> 2020 2017 </li> … … 2024 2021 <li class="indline1">only-if-cached 2025 2022 <ul class="ind"> 2026 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.o.1"><b> 3.2.4</b></a></li>2023 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.o.1"><b>15.2.4</b></a></li> 2027 2024 </ul> 2028 2025 </li> … … 2030 2027 </li> 2031 2028 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2032 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1"> 2.2.3</a>, <a class="iref" href="#rfc.xref.Part1.2">2.5.1</a>, <a class="iref" href="#rfc.xref.Part1.3">2.5.2</a>, <a class="iref" href="#rfc.xref.Part1.4">2.5.2</a>, <a class="iref" href="#rfc.xref.Part1.5">2.6</a>, <a class="iref" href="#rfc.xref.Part1.6">3.3</a>, <a class="iref" href="#Part1"><b>7.1</b></a>, <a class="iref" href="#rfc.xref.Part1.7">A.1</a><ul class="ind">2033 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.6"> 3.3</a></li>2034 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.5"> 2.6</a></li>2035 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.3"> 2.5.2</a>, <a class="iref" href="#rfc.xref.Part1.4">2.5.2</a></li>2036 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part1.2"> 2.5.1</a></li>2037 <li class="indline1"><em>Section 8.3</em> <a class="iref" href="#rfc.xref.Part1.1"> 2.2.3</a></li>2029 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">3.3</a>, <a class="iref" href="#rfc.xref.Part1.2">6.1</a>, <a class="iref" href="#rfc.xref.Part1.3">6.2</a>, <a class="iref" href="#rfc.xref.Part1.4">6.2</a>, <a class="iref" href="#rfc.xref.Part1.5">7</a>, <a class="iref" href="#rfc.xref.Part1.6">15.3</a>, <a class="iref" href="#Part1"><b>19.1</b></a>, <a class="iref" href="#rfc.xref.Part1.7">A.1</a><ul class="ind"> 2030 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.6">15.3</a></li> 2031 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.5">7</a></li> 2032 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.3">6.2</a>, <a class="iref" href="#rfc.xref.Part1.4">6.2</a></li> 2033 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part1.2">6.1</a></li> 2034 <li class="indline1"><em>Section 8.3</em> <a class="iref" href="#rfc.xref.Part1.1">3.3</a></li> 2038 2035 </ul> 2039 2036 </li> 2040 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1"> 2.9</a>, <a class="iref" href="#Part2"><b>7.1</b></a><ul class="ind">2041 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2.1"> 2.9</a></li>2037 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">10</a>, <a class="iref" href="#Part2"><b>19.1</b></a><ul class="ind"> 2038 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">10</a></li> 2042 2039 </ul> 2043 2040 </li> 2044 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1"> 2.5.2</a>, <a class="iref" href="#rfc.xref.Part3.2">2.6</a>, <a class="iref" href="#Part3"><b>7.1</b></a>, <a class="iref" href="#rfc.xref.Part3.3">A.1</a><ul class="ind">2045 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.Part3.1"> 2.5.2</a></li>2046 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.2"> 2.6</a></li>2041 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">6.2</a>, <a class="iref" href="#rfc.xref.Part3.2">7</a>, <a class="iref" href="#Part3"><b>19.1</b></a>, <a class="iref" href="#rfc.xref.Part3.3">A.1</a><ul class="ind"> 2042 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.Part3.1">6.2</a></li> 2043 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.2">7</a></li> 2047 2044 </ul> 2048 2045 </li> 2049 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1"> 2.3</a>, <a class="iref" href="#rfc.xref.Part4.2">2.3.2</a>, <a class="iref" href="#rfc.xref.Part4.3">2.3.2</a>, <a class="iref" href="#Part4"><b>7.1</b></a><ul class="ind">2050 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part4.2"> 2.3.2</a></li>2051 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.1"> 2.3</a></li>2052 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part4.3"> 2.3.2</a></li>2046 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">4</a>, <a class="iref" href="#rfc.xref.Part4.2">4.2</a>, <a class="iref" href="#rfc.xref.Part4.3">4.2</a>, <a class="iref" href="#Part4"><b>19.1</b></a><ul class="ind"> 2047 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part4.2">4.2</a></li> 2048 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.1">4</a></li> 2049 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part4.3">4.2</a></li> 2053 2050 </ul> 2054 2051 </li> 2055 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1"> 2.5.3</a>, <a class="iref" href="#rfc.xref.Part5.2">2.8</a>, <a class="iref" href="#Part5"><b>7.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind">2056 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.1"> 2.5.3</a>, <a class="iref" href="#rfc.xref.Part5.2">2.8</a></li>2052 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">6.3</a>, <a class="iref" href="#rfc.xref.Part5.2">9</a>, <a class="iref" href="#Part5"><b>19.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind"> 2053 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.1">6.3</a>, <a class="iref" href="#rfc.xref.Part5.2">9</a></li> 2057 2054 </ul> 2058 2055 </li> 2059 <li class="indline1"><em>Part7</em> <a class="iref" href="#rfc.xref.Part7.1"> 2.4</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.1</a>, <a class="iref" href="#Part7"><b>7.1</b></a><ul class="ind">2060 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part7.1"> 2.4</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.1</a></li>2056 <li class="indline1"><em>Part7</em> <a class="iref" href="#rfc.xref.Part7.1">5</a>, <a class="iref" href="#rfc.xref.Part7.2">15.2.1</a>, <a class="iref" href="#Part7"><b>19.1</b></a><ul class="ind"> 2057 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part7.1">5</a>, <a class="iref" href="#rfc.xref.Part7.2">15.2.1</a></li> 2061 2058 </ul> 2062 2059 </li> 2063 <li class="indline1">Pragma header <a class="iref" href="#rfc.xref.header.pragma.1"> 3.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>3.4</b></a></li>2060 <li class="indline1">Pragma header <a class="iref" href="#rfc.xref.header.pragma.1">15.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>15.4</b></a></li> 2064 2061 <li class="indline1">private 2065 2062 <ul class="ind"> 2066 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.2"><b> 3.2.1</b></a></li>2063 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.2"><b>15.2.1</b></a></li> 2067 2064 </ul> 2068 2065 </li> 2069 2066 <li class="indline1">proxy-revalidate 2070 2067 <ul class="ind"> 2071 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.3"><b> 3.2.4</b></a></li>2068 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.3"><b>15.2.4</b></a></li> 2072 2069 </ul> 2073 2070 </li> 2074 2071 <li class="indline1">public 2075 2072 <ul class="ind"> 2076 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.1"><b> 3.2.1</b></a></li>2073 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.1"><b>15.2.1</b></a></li> 2077 2074 </ul> 2078 2075 </li> … … 2080 2077 </li> 2081 2078 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 2082 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1"> 2.2.3</a>, <a class="iref" href="#RFC1305"><b>7.2</b></a></li>2083 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1"> 3.6</a>, <a class="iref" href="#RFC2047"><b>7.1</b></a></li>2084 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1. 1</a>, <a class="iref" href="#RFC2119"><b>7.1</b></a></li>2085 <li class="indline1"><em>RFC2616</em> <a class="iref" href="# rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li>2079 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">3.3</a>, <a class="iref" href="#RFC1305"><b>19.2</b></a></li> 2080 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">15.6</a>, <a class="iref" href="#RFC2047"><b>19.1</b></a></li> 2081 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.3</a>, <a class="iref" href="#RFC2119"><b>19.1</b></a></li> 2082 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#RFC2616"><b>19.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li> 2086 2083 </ul> 2087 2084 </li> … … 2089 2086 <li class="indline1">s-maxage 2090 2087 <ul class="ind"> 2091 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.s.3"><b> 3.2.3</b></a></li>2088 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.s.3"><b>15.2.3</b></a></li> 2092 2089 </ul> 2093 2090 </li> 2094 <li class="indline1">semantically transparent <a class="iref" href="#rfc.iref.s. 2">1.2</a></li>2095 <li class="indline1">stale <a class="iref" href="#rfc.iref.s. 1">1.2</a></li>2091 <li class="indline1">semantically transparent <a class="iref" href="#rfc.iref.s.1">1.1</a></li> 2092 <li class="indline1">stale <a class="iref" href="#rfc.iref.s.2">1.2</a></li> 2096 2093 </ul> 2097 2094 </li> 2098 2095 <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind"> 2099 2096 <li class="indline1">validator <a class="iref" href="#rfc.iref.v.1">1.2</a></li> 2100 <li class="indline1">Vary header <a class="iref" href="#rfc.xref.header.vary.1"> 2.6</a>, <a class="iref" href="#rfc.iref.v.2"><b>3.5</b></a></li>2097 <li class="indline1">Vary header <a class="iref" href="#rfc.xref.header.vary.1">7</a>, <a class="iref" href="#rfc.iref.v.2"><b>15.5</b></a></li> 2101 2098 </ul> 2102 2099 </li> 2103 2100 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 2104 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">2.1 .1</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.1.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.1.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">2.5.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">2.5.3</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li>2101 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">2.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">6.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">6.3</a>, <a class="iref" href="#rfc.iref.w.1"><b>15.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li> 2105 2102 </ul> 2106 2103 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r154 r157 215 215 </front> 216 216 <middle> 217 <section title="Introduction" anchor="introduction"> 218 <t> 219 This document will define aspects of HTTP related to caching response 220 messages. Right now it only includes the extracted relevant sections 221 of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> without edit. 222 </t> 223 224 <section title="Requirements" anchor="intro.requirements"> 225 <t> 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in <xref target="RFC2119"/>. 229 </t> 230 <t> 231 An implementation is not compliant if it fails to satisfy one or more 232 of the &MUST; or &REQUIRED; level requirements for the protocols it 233 implements. An implementation that satisfies all the &MUST; or &REQUIRED; 234 level and all the &SHOULD; level requirements for its protocols is said 235 to be "unconditionally compliant"; one that satisfies all the &MUST; 236 level requirements but not all the &SHOULD; level requirements for its 237 protocols is said to be "conditionally compliant." 217 <section title="Introduction" anchor="caching"> 218 <t> 219 HTTP is typically used for distributed information systems, where 220 performance can be improved by the use of response caches. The 221 HTTP/1.1 protocol includes a number of elements intended to make 222 caching work as well as possible. Because these elements are 223 inextricable from other aspects of the protocol, and because they 224 interact with each other, it is useful to describe the basic caching 225 design of HTTP separately from the detailed descriptions of methods, 226 headers, response codes, etc. This document defines aspects of HTTP 227 related to caching response messages. 228 </t> 229 230 <section title="Purpose" anchor="intro.purpose"> 231 <iref item="cache"/> 232 <t> 233 An HTTP <x:dfn>cache</x:dfn> is a local store of response messages 234 and the subsystem that controls its message storage, retrieval, and 235 deletion. A cache stores cacheable responses in order to reduce the 236 response time and network bandwidth consumption on future, equivalent 237 requests. Any client or server may include a cache, though a cache 238 cannot be used by a server that is acting as a tunnel. 239 </t> 240 <t> 241 Caching would be useless if it did not significantly improve 242 performance. The goal of caching in HTTP/1.1 is to eliminate the need 243 to send requests in many cases, and to eliminate the need to send 244 full responses in many other cases. The former reduces the number of 245 network round-trips required for many operations; we use an 246 "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The 247 latter reduces network bandwidth requirements; we use a "validation" 248 mechanism for this purpose (see <xref target="validation.model"/>). 249 </t> 250 <iref item="semantically transparent"/> 251 <t> 252 A cache behaves in a "<x:dfn>semantically transparent</x:dfn>" manner, with 253 respect to a particular response, when its use affects neither the 254 requesting client nor the origin server, except to improve 255 performance. When a cache is semantically transparent, the client 256 receives exactly the same response (except for hop-by-hop headers) 257 that it would have received had its request been handled directly 258 by the origin server. 259 </t> 260 <t> 261 In an ideal world, all interactions with an HTTP cache would be 262 semantically transparent. However, for some resources, semantic 263 transparency is not always necessary and can be effectively traded 264 for the sake of bandwidth scaling, disconnected operation, and 265 high availability. HTTP/1.1 allows origin servers, caches, 266 and clients to explicitly reduce transparency when necessary. 267 However, because non-transparent operation may confuse non-expert 268 users and might be incompatible with certain server applications 269 (such as those for ordering merchandise), the protocol requires that 270 transparency be relaxed 271 <list style="symbols"> 272 <t>only by an explicit protocol-level request when relaxed by 273 client or origin server</t> 274 275 <t>only with an explicit warning to the end user when relaxed by 276 cache or client</t> 277 </list> 278 </t> 279 <t> 280 Therefore, HTTP/1.1 provides these important elements: 281 <list style="numbers"> 282 <t>Protocol features that provide full semantic transparency when 283 this is required by all parties.</t> 284 285 <t>Protocol features that allow an origin server or user agent to 286 explicitly request and control non-transparent operation.</t> 287 288 <t>Protocol features that allow a cache to attach warnings to 289 responses that do not preserve the requested approximation of 290 semantic transparency.</t> 291 </list> 292 </t> 293 <t> 294 A basic principle is that it must be possible for the clients to 295 detect any potential relaxation of semantic transparency. 296 <list><t> 297 <x:h>Note:</x:h> The server, cache, or client implementor might be faced with 298 design decisions not explicitly discussed in this specification. 299 If a decision might affect semantic transparency, the implementor 300 ought to err on the side of maintaining transparency unless a 301 careful and complete analysis shows significant benefits in 302 breaking transparency. 303 </t></list> 238 304 </t> 239 305 </section> … … 242 308 <t> 243 309 This specification uses a number of terms to refer to the roles 244 played by participants in, and objects of, the HTTP communication. 245 </t> 246 <t> 247 <iref item="cache"/> 248 <x:dfn>cache</x:dfn> 249 <list> 250 <t> 251 A program's local store of response messages and the subsystem 252 that controls its message storage, retrieval, and deletion. A 253 cache stores cacheable responses in order to reduce the response 254 time and network bandwidth consumption on future, equivalent 255 requests. Any client or server may include a cache, though a cache 256 cannot be used by a server that is acting as a tunnel. 257 </t> 258 </list> 310 played by participants in, and objects of, HTTP caching. 259 311 </t> 260 312 <t> … … 264 316 <t> 265 317 A response is cacheable if a cache is allowed to store a copy of 266 the response message for use in answering subsequent requests. The 267 rules for determining the cacheability of HTTP responses are 268 defined in <xref target="caching"/>. Even if a resource is cacheable, there may 318 the response message for use in answering subsequent requests. 319 Even if a resource is cacheable, there may 269 320 be additional constraints on whether a cache can use the cached 270 321 copy for a particular request. … … 344 395 </t> 345 396 <t> 346 <iref item="semantically transparent"/>347 <x:dfn>semantically transparent</x:dfn>348 <list>349 <t>350 A cache behaves in a "semantically transparent" manner, with351 respect to a particular response, when its use affects neither the352 requesting client nor the origin server, except to improve353 performance. When a cache is semantically transparent, the client354 receives exactly the same response (except for hop-by-hop headers)355 that it would have received had its request been handled directly356 by the origin server.357 </t>358 </list>359 </t>360 <t>361 397 <iref item="validator"/> 362 398 <x:dfn>validator</x:dfn> … … 371 407 </section> 372 408 373 <section title="Delta Seconds" anchor="delta.seconds"> 374 <t> 375 Some HTTP header fields allow a time value to be specified as an 376 integer number of seconds, represented in decimal, after the time 377 that the message was received. 378 </t> 379 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/> 380 delta-seconds = 1*DIGIT 381 </artwork></figure> 382 </section> 383 </section> 384 385 <section title="Caching in HTTP" anchor="caching"> 409 <section title="Requirements" anchor="intro.requirements"> 410 <t> 411 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 412 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 413 document are to be interpreted as described in <xref target="RFC2119"/>. 414 </t> 415 <t> 416 An implementation is not compliant if it fails to satisfy one or more 417 of the &MUST; or &REQUIRED; level requirements for the protocols it 418 implements. An implementation that satisfies all the &MUST; or &REQUIRED; 419 level and all the &SHOULD; level requirements for its protocols is said 420 to be "unconditionally compliant"; one that satisfies all the &MUST; 421 level requirements but not all the &SHOULD; level requirements for its 422 protocols is said to be "conditionally compliant." 423 </t> 424 </section> 425 </section> 426 386 427 <section title="Overview" anchor="caching.overview"> 387 <t>388 HTTP is typically used for distributed information systems, where389 performance can be improved by the use of response caches. The390 HTTP/1.1 protocol includes a number of elements intended to make391 caching work as well as possible. Because these elements are392 inextricable from other aspects of the protocol, and because they393 interact with each other, it is useful to describe the basic caching394 design of HTTP separately from the detailed descriptions of methods,395 headers, response codes, etc.396 </t>397 <t>398 Caching would be useless if it did not significantly improve399 performance. The goal of caching in HTTP/1.1 is to eliminate the need400 to send requests in many cases, and to eliminate the need to send401 full responses in many other cases. The former reduces the number of402 network round-trips required for many operations; we use an403 "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The404 latter reduces network bandwidth requirements; we use a "validation"405 mechanism for this purpose (see <xref target="validation.model"/>).406 </t>407 <t>408 Requirements for performance, availability, and disconnected409 operation require us to be able to relax the goal of semantic410 transparency. The HTTP/1.1 protocol allows origin servers, caches,411 and clients to explicitly reduce transparency when necessary.412 However, because non-transparent operation may confuse non-expert413 users, and might be incompatible with certain server applications414 (such as those for ordering merchandise), the protocol requires that415 transparency be relaxed416 <list style="symbols">417 <t>only by an explicit protocol-level request when relaxed by418 client or origin server</t>419 420 <t>only with an explicit warning to the end user when relaxed by421 cache or client</t>422 </list>423 </t>424 <t>425 Therefore, the HTTP/1.1 protocol provides these important elements:426 <list style="numbers">427 <t>Protocol features that provide full semantic transparency when428 this is required by all parties.</t>429 430 <t>Protocol features that allow an origin server or user agent to431 explicitly request and control non-transparent operation.</t>432 433 <t>Protocol features that allow a cache to attach warnings to434 responses that do not preserve the requested approximation of435 semantic transparency.</t>436 </list>437 </t>438 <t>439 A basic principle is that it must be possible for the clients to440 detect any potential relaxation of semantic transparency.441 <list><t>442 <x:h>Note:</x:h> The server, cache, or client implementor might be faced with443 design decisions not explicitly discussed in this specification.444 If a decision might affect semantic transparency, the implementor445 ought to err on the side of maintaining transparency unless a446 careful and complete analysis shows significant benefits in447 breaking transparency.448 </t></list>449 </t>450 451 428 <section title="Cache Correctness" anchor="cache.correctness"> 452 429 <t> … … 1532 1509 </t> 1533 1510 </section> 1534 </section>1535 1511 1536 1512 <section title="Header Field Definitions" anchor="header.fields"> … … 1562 1538 seconds. 1563 1539 </t> 1540 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/> 1541 delta-seconds = 1*DIGIT 1542 </artwork></figure> 1564 1543 <t> 1565 1544 If a cache receives a value larger than the largest positive
Note: See TracChangeset
for help on using the changeset viewer.