Changeset 205 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 06/02/08 19:15:29 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r204 r205 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 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"> 335 <link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Overview" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 Expiration Model" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Validation Model" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 Response Cacheability" href="#rfc.section.6"> 340 <link rel="Chapter" title="7 Constructing Responses From Caches" href="#rfc.section.7"> 341 <link rel="Chapter" title="8 Caching Negotiated Responses" href="#rfc.section.8"> 342 <link rel="Chapter" title="9 Shared and Non-Shared Caches" href="#rfc.section.9"> 343 <link rel="Chapter" title="10 Errors or Incomplete Response Cache Behavior" href="#rfc.section.10"> 344 <link rel="Chapter" title="11 Side Effects of GET and HEAD" href="#rfc.section.11"> 345 <link rel="Chapter" title="12 Invalidation After Updates or Deletions" href="#rfc.section.12"> 346 <link rel="Chapter" title="13 Write-Through Mandatory" href="#rfc.section.13"> 347 <link rel="Chapter" title="14 Cache Replacement" href="#rfc.section.14"> 348 <link rel="Chapter" title="15 History Lists" href="#rfc.section.15"> 349 <link rel="Chapter" title="16 Header Field Definitions" href="#rfc.section.16"> 350 <link rel="Chapter" title="17 IANA Considerations" href="#rfc.section.17"> 351 <link rel="Chapter" title="18 Security Considerations" href="#rfc.section.18"> 352 <link rel="Chapter" title="19 Acknowledgments" href="#rfc.section.19"> 353 <link rel="Chapter" href="#rfc.section.20" title="20 References"> 353 354 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 354 355 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> … … 494 495 </ul> 495 496 </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> 497 <li class="tocline0">2. <a href="#notation">Notational Conventions and Generic Grammar</a></li> 498 <li class="tocline0">3. <a href="#caching.overview">Overview</a><ul class="toc"> 499 <li class="tocline1">3.1 <a href="#cache.correctness">Cache Correctness</a></li> 500 <li class="tocline1">3.2 <a href="#warnings">Warnings</a></li> 501 <li class="tocline1">3.3 <a href="#cache-control.mechanisms">Cache-control Mechanisms</a></li> 502 <li class="tocline1">3.4 <a href="#explicit.ua.warnings">Explicit User Agent Warnings</a></li> 503 <li class="tocline1">3.5 <a href="#exceptions.to.the.rules.and.warnings">Exceptions to the Rules and Warnings</a></li> 504 <li class="tocline1">3.6 <a href="#client-controlled.behavior">Client-controlled Behavior</a></li> 503 505 </ul> 504 506 </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>507 <li class="tocline0">4. <a href="#expiration.model">Expiration Model</a><ul class="toc"> 508 <li class="tocline1">4.1 <a href="#server-specified.expiration">Server-Specified Expiration</a></li> 509 <li class="tocline1">4.2 <a href="#heuristic.expiration">Heuristic Expiration</a></li> 510 <li class="tocline1">4.3 <a href="#age.calculations">Age Calculations</a></li> 511 <li class="tocline1">4.4 <a href="#expiration.calculations">Expiration Calculations</a></li> 512 <li class="tocline1">4.5 <a href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></li> 513 <li class="tocline1">4.6 <a href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></li> 512 514 </ul> 513 515 </li> 514 <li class="tocline0"> 4. <a href="#validation.model">Validation Model</a></li>515 <li class="tocline0"> 5. <a href="#response.cacheability">Response Cacheability</a></li>516 <li class="tocline0"> 6. <a href="#constructing.responses.from.caches">Constructing Responses From Caches</a><ul class="toc">517 <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>518 <li class="tocline1"> 6.2 <a href="#non-modifiable.headers">Non-modifiable Headers</a></li>519 <li class="tocline1"> 6.3 <a href="#combining.headers">Combining Headers</a></li>516 <li class="tocline0">5. <a href="#validation.model">Validation Model</a></li> 517 <li class="tocline0">6. <a href="#response.cacheability">Response Cacheability</a></li> 518 <li class="tocline0">7. <a href="#constructing.responses.from.caches">Constructing Responses From Caches</a><ul class="toc"> 519 <li class="tocline1">7.1 <a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li> 520 <li class="tocline1">7.2 <a href="#non-modifiable.headers">Non-modifiable Headers</a></li> 521 <li class="tocline1">7.3 <a href="#combining.headers">Combining Headers</a></li> 520 522 </ul> 521 523 </li> 522 <li class="tocline0"> 7. <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>523 <li class="tocline0"> 8. <a href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></li>524 <li class="tocline0"> 9. <a href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></li>525 <li class="tocline0">1 0. <a href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></li>526 <li class="tocline0">1 1. <a href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></li>527 <li class="tocline0">1 2. <a href="#write-through.mandatory">Write-Through Mandatory</a></li>528 <li class="tocline0">1 3. <a href="#cache.replacement">Cache Replacement</a></li>529 <li class="tocline0">1 4. <a href="#history.lists">History Lists</a></li>530 <li class="tocline0">1 5. <a href="#header.fields">Header Field Definitions</a><ul class="toc">531 <li class="tocline1">1 5.1 <a href="#header.age">Age</a></li>532 <li class="tocline1">1 5.2 <a href="#header.cache-control">Cache-Control</a><ul class="toc">533 <li class="tocline1">1 5.2.1 <a href="#what.is.cacheable">What is Cacheable</a></li>534 <li class="tocline1">1 5.2.2 <a href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></li>535 <li class="tocline1">1 5.2.3 <a href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></li>536 <li class="tocline1">1 5.2.4 <a href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></li>537 <li class="tocline1">1 5.2.5 <a href="#no-transform.directive">No-Transform Directive</a></li>538 <li class="tocline1">1 5.2.6 <a href="#cache.control.extensions">Cache Control Extensions</a></li>524 <li class="tocline0">8. <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 525 <li class="tocline0">9. <a href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></li> 526 <li class="tocline0">10. <a href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></li> 527 <li class="tocline0">11. <a href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></li> 528 <li class="tocline0">12. <a href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></li> 529 <li class="tocline0">13. <a href="#write-through.mandatory">Write-Through Mandatory</a></li> 530 <li class="tocline0">14. <a href="#cache.replacement">Cache Replacement</a></li> 531 <li class="tocline0">15. <a href="#history.lists">History Lists</a></li> 532 <li class="tocline0">16. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 533 <li class="tocline1">16.1 <a href="#header.age">Age</a></li> 534 <li class="tocline1">16.2 <a href="#header.cache-control">Cache-Control</a><ul class="toc"> 535 <li class="tocline1">16.2.1 <a href="#what.is.cacheable">What is Cacheable</a></li> 536 <li class="tocline1">16.2.2 <a href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></li> 537 <li class="tocline1">16.2.3 <a href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></li> 538 <li class="tocline1">16.2.4 <a href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></li> 539 <li class="tocline1">16.2.5 <a href="#no-transform.directive">No-Transform Directive</a></li> 540 <li class="tocline1">16.2.6 <a href="#cache.control.extensions">Cache Control Extensions</a></li> 539 541 </ul> 540 542 </li> 541 <li class="tocline1">1 5.3 <a href="#header.expires">Expires</a></li>542 <li class="tocline1">1 5.4 <a href="#header.pragma">Pragma</a></li>543 <li class="tocline1">1 5.5 <a href="#header.vary">Vary</a></li>544 <li class="tocline1">1 5.6 <a href="#header.warning">Warning</a></li>543 <li class="tocline1">16.3 <a href="#header.expires">Expires</a></li> 544 <li class="tocline1">16.4 <a href="#header.pragma">Pragma</a></li> 545 <li class="tocline1">16.5 <a href="#header.vary">Vary</a></li> 546 <li class="tocline1">16.6 <a href="#header.warning">Warning</a></li> 545 547 </ul> 546 548 </li> 547 <li class="tocline0">1 6. <a href="#IANA.considerations">IANA Considerations</a></li>548 <li class="tocline0">1 7. <a href="#security.considerations">Security Considerations</a></li>549 <li class="tocline0">1 8. <a href="#ack">Acknowledgments</a></li>550 <li class="tocline0"> 19. <a href="#rfc.references">References</a><ul class="toc">551 <li class="tocline1"> 19.1 <a href="#rfc.references.1">Normative References</a></li>552 <li class="tocline1"> 19.2 <a href="#rfc.references.2">Informative References</a></li>549 <li class="tocline0">17. <a href="#IANA.considerations">IANA Considerations</a></li> 550 <li class="tocline0">18. <a href="#security.considerations">Security Considerations</a></li> 551 <li class="tocline0">19. <a href="#ack">Acknowledgments</a></li> 552 <li class="tocline0">20. <a href="#rfc.references">References</a><ul class="toc"> 553 <li class="tocline1">20.1 <a href="#rfc.references.1">Normative References</a></li> 554 <li class="tocline1">20.2 <a href="#rfc.references.2">Informative References</a></li> 553 555 </ul> 554 556 </li> … … 582 584 <p id="rfc.section.1.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to reuse a prior 583 585 response message to satisfy a current request. In some cases, the existing response can be reused without the need for a network 584 request, reducing latency and network round-trips; we use an "expiration" mechanism for this purpose (see <a href="#expiration.model" title="Expiration Model">Section 3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy585 the request, thereby reducing network bandwidth usage; we use a "validation" mechanism for this purpose (see <a href="#validation.model" title="Validation Model">Section 4</a>).586 request, reducing latency and network round-trips; we use an "expiration" mechanism for this purpose (see <a href="#expiration.model" title="Expiration Model">Section 4</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy 587 the request, thereby reducing network bandwidth usage; we use a "validation" mechanism for this purpose (see <a href="#validation.model" title="Validation Model">Section 5</a>). 586 588 </p> 587 589 <div id="rfc.iref.s.1"></div> … … 675 677 <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." 676 678 </p> 677 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Overview</a></h1> 678 <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> 679 <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: 679 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1> 680 <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="Augmented BNF">Section 2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: <span class="comment">[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 5234, see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>.]</span> 681 </p> 682 <div id="rfc.figure.u.1"></div><pre class="inline"> DIGIT = <DIGIT, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 683 DQUOTE = <DQUOTE, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 684 SP = <SP, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 685 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> quoted-string = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 686 token = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 687 </pre><p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 688 <div id="rfc.figure.u.3"></div><pre class="inline"> field-name = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>> 689 HTTP-date = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>> 690 port = <port, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 691 pseudonym = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a>> 692 uri-host = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 693 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="caching.overview" href="#caching.overview">Overview</a></h1> 694 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h2> 695 <p id="rfc.section.3.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">4.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">4.6</a>, and <a href="#cache.replacement" title="Cache Replacement">14</a>) which meets one of the following conditions: 680 696 </p> 681 697 <ol> 682 698 <li>It has been checked for equivalence with what the origin server would have returned by revalidating the response with the 683 origin server (<a href="#validation.model" title="Validation Model">Section 4</a>);684 </li> 685 <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, and686 cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 1 5.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is699 origin server (<a href="#validation.model" title="Validation Model">Section 5</a>); 700 </li> 701 <li>It is "fresh enough" (see <a href="#expiration.model" title="Expiration Model">Section 4</a>). In the default case, this means it meets the least restrictive freshness requirement of the client, origin server, and 702 cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 16.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is 687 703 not "fresh enough" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered 688 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;689 see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 1 5.2</a>).704 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">3.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">16.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive; 705 see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 16.2</a>). 690 706 </li> 691 707 <li>It is an appropriate 304 (Not Modified), 305 (Use Proxy), or error (4xx or 5xx) response message.</li> 692 708 </ol> 693 <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.694 </p> 695 <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 forward709 <p id="rfc.section.3.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. 710 </p> 711 <p id="rfc.section.3.1.p.3">If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward 696 712 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. 697 713 A user agent that receives a stale response without a Warning <em class="bcp14">MAY</em> display a warning indication to the user. 698 714 </p> 699 <h2 id="rfc.section. 2.2"><a href="#rfc.section.2.2">2.2</a> <a id="warnings" href="#warnings">Warnings</a></h2>700 <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 are701 described in <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 1 5.6</a>. The warning allows clients to take appropriate action.702 </p> 703 <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, distinguish715 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="warnings" href="#warnings">Warnings</a></h2> 716 <p id="rfc.section.3.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 3.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 717 described in <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 16.6</a>. The warning allows clients to take appropriate action. 718 </p> 719 <p id="rfc.section.3.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 704 720 these responses from true failures. 705 721 </p> 706 <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:707 </p> 708 <p id="rfc.section. 2.2.p.4"> </p>722 <p id="rfc.section.3.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: 723 </p> 724 <p id="rfc.section.3.2.p.4"> </p> 709 725 <dl> 710 726 <dt>1xx</dt> … … 716 732 </dd> 717 733 </dl> 718 <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.719 </p> 720 <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 responses734 <p id="rfc.section.3.2.p.5">See <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 16.6</a> for the definitions of the codes themselves. 735 </p> 736 <p id="rfc.section.3.2.p.6">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Warnings in responses 721 737 that are passed to HTTP/1.0 caches carry an extra warning-date field, which prevents a future HTTP/1.1 recipient from believing 722 738 an erroneously cached Warning. 723 739 </p> 724 <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.725 </p> 726 <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.740 <p id="rfc.section.3.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. 741 </p> 742 <p id="rfc.section.3.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. 727 743 For example, a server might provide the same warning with texts in both English and Basque. 728 744 </p> 729 <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.745 <p id="rfc.section.3.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. 730 746 This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but 731 747 does suggest some heuristics. 732 748 </p> 733 <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>734 <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.749 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="cache-control.mechanisms" href="#cache-control.mechanisms">Cache-control Mechanisms</a></h2> 750 <p id="rfc.section.3.3.p.1">The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. 735 751 In some cases, a server or client might need to provide explicit directives to the HTTP caches. We use the Cache-Control header 736 752 for this purpose. 737 753 </p> 738 <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. These754 <p id="rfc.section.3.3.p.2">The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These 739 755 directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between 740 756 header values, the most restrictive interpretation is applied (that is, the one that is most likely to preserve semantic transparency). … … 742 758 (for example, "max-stale" or "public"). 743 759 </p> 744 <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>.745 </p> 746 <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>747 <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 allow760 <p id="rfc.section.3.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 16.2</a>. 761 </p> 762 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="explicit.ua.warnings" href="#explicit.ua.warnings">Explicit User Agent Warnings</a></h2> 763 <p id="rfc.section.3.4.p.1">Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent might allow 748 764 the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually 749 765 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. 750 766 </p> 751 <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 transparency767 <p id="rfc.section.3.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 752 768 requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent 753 769 to determine if responses are stale or not, this indication need only be displayed when this actually happens. The indication 754 770 need not be a dialog box; it could be an icon (for example, a picture of a rotting fish) or some other indicator. 755 771 </p> 756 <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 user772 <p id="rfc.section.3.4.p.3">If the user has overridden the caching mechanisms in a way that would abnormally reduce the effectiveness of caches, the user 757 773 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 758 774 does not inadvertently consume excess resources or suffer from excessive latency. 759 775 </p> 760 <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>761 <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,776 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.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> 777 <p id="rfc.section.3.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, 762 778 but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin 763 779 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. 764 780 </p> 765 <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 for781 <p id="rfc.section.3.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 766 782 technical or policy reasons. 767 783 </p> 768 <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>769 <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) are784 <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a> <a id="client-controlled.behavior" href="#client-controlled.behavior">Client-controlled Behavior</a></h2> 785 <p id="rfc.section.3.6.p.1">While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are 770 786 the primary source of expiration information, in some cases the client might need to control a cache's decision about whether 771 787 to return a cached response without validating it. Clients do this using several directives of the Cache-Control header. 772 788 </p> 773 <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)789 <p id="rfc.section.3.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) 774 790 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 775 791 of caches, and so cannot further relax the cache's approximation of semantic transparency. 776 792 </p> 777 <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 on793 <p id="rfc.section.3.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 778 794 the caches, and so might violate the origin server's specified constraints on semantic transparency, but might be necessary 779 795 to support disconnected operation, or high availability in the face of poor connectivity. 780 796 </p> 781 <h1 id="rfc.section. 3"><a href="#rfc.section.3">3.</a> <a id="expiration.model" href="#expiration.model">Expiration Model</a></h1>782 <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>783 <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 avoiding797 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="expiration.model" href="#expiration.model">Expiration Model</a></h1> 798 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="server-specified.expiration" href="#server-specified.expiration">Server-Specified Expiration</a></h2> 799 <p id="rfc.section.4.1.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding 784 800 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. 785 801 </p> 786 <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 is802 <p id="rfc.section.4.1.p.2">Our expectation is that servers will assign future explicit expiration times to responses in the belief that the entity is 787 803 not likely to change, in a semantically significant way, before the expiration time is reached. This normally preserves semantic 788 804 transparency, as long as the server's expiration times are carefully chosen. 789 805 </p> 790 <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 immediately806 <p id="rfc.section.4.1.p.3">The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately 791 807 to the requesting client. 792 808 </p> 793 <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.794 </p> 795 <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>).796 </p> 797 <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>798 <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 only809 <p id="rfc.section.4.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 16.2.4</a> for a more restrictive way to force revalidation. 810 </p> 811 <p id="rfc.section.4.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 16.2</a>). 812 </p> 813 <p id="rfc.section.4.1.p.6">Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.</p> 814 <p id="rfc.section.4.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 799 815 to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource 800 is initiated. See <a href="#history.lists" title="History Lists">Section 1 4</a> for an explanation of the difference between caches and history mechanisms.801 </p> 802 <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>803 <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,816 is initiated. See <a href="#history.lists" title="History Lists">Section 15</a> for an explanation of the difference between caches and history mechanisms. 817 </p> 818 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="heuristic.expiration" href="#heuristic.expiration">Heuristic Expiration</a></h2> 819 <p id="rfc.section.4.2.p.1">Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, 804 820 employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. 805 821 The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. … … 807 823 origin servers to provide explicit expiration times as much as possible. 808 824 </p> 809 <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>810 <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 how811 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.812 </p> 813 <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."825 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="age.calculations" href="#age.calculations">Age Calculations</a></h2> 826 <p id="rfc.section.4.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 827 to calculate the latter in <a href="#expiration.calculations" title="Expiration Calculations">Section 4.4</a>; this section describes how to calculate the age of a response or cache entry. 828 </p> 829 <p id="rfc.section.4.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 830 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. 815 831 </p> 816 <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 response817 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.818 </p> 819 <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. The832 <p id="rfc.section.4.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 833 was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations. 834 </p> 835 <p id="rfc.section.4.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 820 836 Age field value is the cache's estimate of the amount of time since the response was generated or revalidated by the origin 821 837 server. 822 838 </p> 823 <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 path839 <p id="rfc.section.4.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 824 840 from the origin server, plus the amount of time it has been in transit along network paths. 825 841 </p> 826 <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>827 <p id="rfc.section. 3.3.p.7">A response's age can be calculated in two entirely independent ways: </p>842 <p id="rfc.section.4.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> 843 <p id="rfc.section.4.3.p.7">A response's age can be calculated in two entirely independent ways: </p> 828 844 <ol> 829 845 <li>now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, … … 832 848 <li>age_value, if all of the caches along the response path implement HTTP/1.1.</li> 833 849 </ol> 834 <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>835 <div id="rfc.figure.u. 1"></div><pre class="text"> corrected_received_age = max(now - date_value, age_value)836 </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>837 <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 response850 <p id="rfc.section.4.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> 851 <div id="rfc.figure.u.4"></div><pre class="text"> corrected_received_age = max(now - date_value, age_value) 852 </pre><p id="rfc.section.4.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> 853 <p id="rfc.section.4.3.p.11">Because of network-imposed delays, some significant interval might pass between the time that a server generates a response 838 854 and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low 839 855 ages. 840 856 </p> 841 <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,857 <p id="rfc.section.4.3.p.12">Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, 842 858 we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age 843 859 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 844 860 results in conservative behavior no matter how much delay is experienced. So, we compute: 845 861 </p> 846 <div id="rfc.figure.u. 2"></div><pre class="text"> corrected_initial_age = corrected_received_age862 <div id="rfc.figure.u.5"></div><pre class="text"> corrected_initial_age = corrected_received_age 847 863 + (now - request_time) 848 </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>849 <p id="rfc.section. 3.3.p.15">Summary of age calculation algorithm, when a cache receives a response:</p>850 <div id="rfc.figure.u. 3"></div><pre class="text"> /*864 </pre><p id="rfc.section.4.3.p.14">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p> 865 <p id="rfc.section.4.3.p.15">Summary of age calculation algorithm, when a cache receives a response:</p> 866 <div id="rfc.figure.u.6"></div><pre class="text"> /* 851 867 * age_value 852 868 * is the value of Age: header received by the cache with … … 870 886 resident_time = now - response_time; 871 887 current_age = corrected_initial_age + resident_time; 872 </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 validated888 </pre><p id="rfc.section.4.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 873 889 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. 874 890 </p> 875 <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 not891 <p id="rfc.section.4.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 876 892 true, since the lack of an Age header field in a response does not imply that the response is first-hand unless all caches 877 893 along the request path are compliant with HTTP/1.1 (i.e., older HTTP caches did not implement the Age header field). 878 894 </p> 879 <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>880 <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 is881 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 discussion895 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="expiration.calculations" href="#expiration.calculations">Expiration Calculations</a></h2> 896 <p id="rfc.section.4.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 897 calculated as described in <a href="#age.calculations" title="Age Calculations">Section 4.3</a>; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion 882 898 below, the values can be represented in any form appropriate for arithmetic operations. 883 899 </p> 884 <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 appropriate885 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 1 5.2.3</a>).886 </p> 887 <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>888 <div id="rfc.figure.u. 4"></div><pre class="text"> freshness_lifetime = max_age_value889 </pre><p id="rfc.section. 3.4.p.5">Otherwise, if Expires is present in the response, the calculation is:</p>890 <div id="rfc.figure.u. 5"></div><pre class="text"> freshness_lifetime = expires_value - date_value891 </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>892 <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.893 </p> 894 <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%.895 </p> 896 <p id="rfc.section. 3.4.p.10">The calculation to determine if a response has expired is quite simple:</p>897 <div id="rfc.figure.u. 6"></div><pre class="text"> response_is_fresh = (freshness_lifetime > current_age)898 </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>899 <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 same900 <p id="rfc.section.4.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 901 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 16.2.3</a>). 902 </p> 903 <p id="rfc.section.4.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> 904 <div id="rfc.figure.u.7"></div><pre class="text"> freshness_lifetime = max_age_value 905 </pre><p id="rfc.section.4.4.p.5">Otherwise, if Expires is present in the response, the calculation is:</p> 906 <div id="rfc.figure.u.8"></div><pre class="text"> freshness_lifetime = expires_value - date_value 907 </pre><p id="rfc.section.4.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> 908 <p id="rfc.section.4.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 16.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. 909 </p> 910 <p id="rfc.section.4.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%. 911 </p> 912 <p id="rfc.section.4.4.p.10">The calculation to determine if a response has expired is quite simple:</p> 913 <div id="rfc.figure.u.9"></div><pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 914 </pre><h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a id="disambiguating.expiration.values" href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></h2> 915 <p id="rfc.section.4.5.p.1">Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same 900 916 resource that are different. 901 917 </p> 902 <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,903 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 1 5.2</a>), to force a check with the origin server.904 </p> 905 <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 other918 <p id="rfc.section.4.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, 919 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 16.2</a>), to force a check with the origin server. 920 </p> 921 <p id="rfc.section.4.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 906 922 caches, or because a client has asked for a reload or a revalidation of an apparently fresh cache entry. 907 923 </p> 908 <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>909 <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 and924 <h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a> <a id="disambiguating.multiple.responses" href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></h2> 925 <p id="rfc.section.4.6.p.1">Because a client might be receiving responses via multiple paths, so that some responses flow through one set of caches and 910 926 other responses flow through a different set of caches, a client might receive responses in an order different from that in 911 927 which the origin server sent them. We would like the client to use the most recently generated response, even if older responses 912 928 are still apparently fresh. 913 929 </p> 914 <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 response930 <p id="rfc.section.4.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 915 931 intentionally carries an earlier expiration time. The Date values are ordered to a granularity of one second. 916 932 </p> 917 <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 older933 <p id="rfc.section.4.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 918 934 than the one for the existing entry, then the client <em class="bcp14">SHOULD</em> repeat the request unconditionally, and include 919 935 </p> 920 <div id="rfc.figure.u. 7"></div><pre class="text"> Cache-Control: max-age=0921 </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>922 <div id="rfc.figure.u. 8"></div><pre class="text"> Cache-Control: no-cache923 </pre><p id="rfc.section. 3.6.p.7">to force any intermediate caches to obtain a new copy from the origin server.</p>924 <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 expiration936 <div id="rfc.figure.u.10"></div><pre class="text"> Cache-Control: max-age=0 937 </pre><p id="rfc.section.4.6.p.5">to force any intermediate caches to validate their copies directly with the origin server, or</p> 938 <div id="rfc.figure.u.11"></div><pre class="text"> Cache-Control: no-cache 939 </pre><p id="rfc.section.4.6.p.7">to force any intermediate caches to obtain a new copy from the origin server.</p> 940 <p id="rfc.section.4.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 925 941 times overlap. 926 942 </p> 927 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> <a id="validation.model" href="#validation.model">Validation Model</a></h1>928 <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 the943 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="validation.model" href="#validation.model">Validation Model</a></h1> 944 <p id="rfc.section.5.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 929 945 origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call 930 946 this "validating" the cache entry. 931 947 </p> 932 <p id="rfc.section. 4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the cached entry is valid. When a cached response includes one948 <p id="rfc.section.5.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the cached entry is valid. When a cached response includes one 933 949 or more "cache validators," such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state 934 950 of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the … … 937 953 be satisfied and the cache entry supplanted without the need for an additional network round-trip. 938 954 </p> 939 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h1>940 <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 with955 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h1> 956 <p id="rfc.section.6.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 16.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 10</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 941 957 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 942 958 such a response was taken from a cache by comparing the Date header to the current time. … … 946 962 </dd> 947 963 </dl> 948 <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 subsequent964 <p id="rfc.section.6.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 949 965 request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security 950 966 or privacy considerations. Certain cache-control directives are therefore provided so that the server can indicate that certain 951 967 resource entities, or portions thereof, are not to be cached regardless of other considerations. 952 968 </p> 953 <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 Authorization969 <p id="rfc.section.6.p.3">Note that <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.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 954 970 header. 955 971 </p> 956 <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-control972 <p id="rfc.section.6.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 957 973 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. 958 974 </p> 959 <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 explicitly960 allow it. For example, these include the following: an Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 1 5.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>).961 </p> 962 <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>963 <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.975 <p id="rfc.section.6.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 976 allow it. For example, these include the following: an Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 16.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 16.2</a>). 977 </p> 978 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses From Caches</a></h1> 979 <p id="rfc.section.7.p.1">The purpose of an HTTP cache is to store information received in response to requests for use in responding to future requests. 964 980 In many cases, a cache simply returns the appropriate parts of a response to the requester. However, if the cache holds a 965 981 cache entry based on a previous response, it might have to combine parts of a new response with what is held in the cache 966 982 entry. 967 983 </p> 968 <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>969 <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>984 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.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> 985 <p id="rfc.section.7.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: </p> 970 986 <ul> 971 987 <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. … … 975 991 </li> 976 992 </ul> 977 <p id="rfc.section. 6.1.p.2">The following HTTP/1.1 headers are hop-by-hop headers: </p>993 <p id="rfc.section.7.1.p.2">The following HTTP/1.1 headers are hop-by-hop headers: </p> 978 994 <ul> 979 995 <li>Connection</li> … … 986 1002 <li>Upgrade</li> 987 1003 </ul> 988 <p id="rfc.section. 6.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p>989 <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>).990 </p> 991 <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>992 <p id="rfc.section. 6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent1004 <p id="rfc.section.7.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p> 1005 <p id="rfc.section.7.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.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1006 </p> 1007 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h2> 1008 <p id="rfc.section.7.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent 993 1009 proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that. 994 1010 </p> 995 <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:1011 <p id="rfc.section.7.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: 996 1012 </p> 997 1013 <ul> … … 1001 1017 <li>Last-Modified</li> 1002 1018 </ul> 1003 <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:1019 <p id="rfc.section.7.2.p.3">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: 1004 1020 </p> 1005 1021 <ul> 1006 1022 <li>Expires</li> 1007 1023 </ul> 1008 <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.1009 </p> 1010 <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:1024 <p id="rfc.section.7.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. 1025 </p> 1026 <p id="rfc.section.7.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: 1011 1027 </p> 1012 1028 <ul> … … 1015 1031 <li>Content-Type</li> 1016 1032 </ul> 1017 <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>).1033 <p id="rfc.section.7.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 16.6</a>). 1018 1034 </p> 1019 1035 <dl class="empty"> … … 1022 1038 </dd> 1023 1039 </dl> 1024 <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>).1025 </p> 1026 <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>1027 <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 (Partial1040 <p id="rfc.section.7.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.15"><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 4.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.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1041 </p> 1042 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="combining.headers" href="#combining.headers">Combining Headers</a></h2> 1043 <p id="rfc.section.7.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 1028 1044 Content) response, the cache then constructs a response to send to the requesting client. 1029 1045 </p> 1030 <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 this1046 <p id="rfc.section.7.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 1031 1047 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 1032 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>).1033 </p> 1034 <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>1048 of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section 5</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>). 1049 </p> 1050 <p id="rfc.section.7.3.p.3">The end-to-end headers stored in the cache entry are used for the constructed response, except that </p> 1035 1051 <ul> 1036 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 1 5.6</a>) <em class="bcp14">MUST</em> be deleted from the cache entry and the forwarded response.1052 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 16.6</a>) <em class="bcp14">MUST</em> be deleted from the cache entry and the forwarded response. 1037 1053 </li> 1038 1054 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the cache entry and the forwarded response. … … 1041 1057 </li> 1042 1058 </ul> 1043 <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,1059 <p id="rfc.section.7.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, 1044 1060 except for Warning headers as described immediately above. If a header field-name in the incoming response matches more than 1045 1061 one header in the cache entry, all such old headers <em class="bcp14">MUST</em> be replaced. 1046 1062 </p> 1047 <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 headers1063 <p id="rfc.section.7.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 1048 1064 stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden). 1049 1065 </p> … … 1055 1071 </dd> 1056 1072 </dl> 1057 <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>1058 <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 cache1059 can use the response for subsequent requests. See <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 1 5.5</a> for use of the Vary header field by servers.1060 </p> 1061 <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 representations1073 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h1> 1074 <p id="rfc.section.8.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 5.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 1075 can use the response for subsequent requests. See <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 16.5</a> for use of the Vary header field by servers. 1076 </p> 1077 <p id="rfc.section.8.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 1062 1078 of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known 1063 1079 as the "selecting" request-headers. 1064 1080 </p> 1065 <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 header1081 <p id="rfc.section.8.p.3">When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header 1066 1082 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 1067 1083 new request match the corresponding stored request-headers in the original request. 1068 1084 </p> 1069 <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 first1085 <p id="rfc.section.8.p.4">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 1070 1086 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space 1071 1087 (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same 1072 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>.1073 </p> 1074 <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 interpreted1088 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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1089 </p> 1090 <p id="rfc.section.8.p.5">A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted 1075 1091 by the origin server. 1076 1092 </p> 1077 <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,1093 <p id="rfc.section.8.p.6">If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, 1078 1094 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 1079 1095 and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to 1080 1096 be used. 1081 1097 </p> 1082 <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. This1098 <p id="rfc.section.8.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 1083 1099 conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested 1084 1100 entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. 1085 1101 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. 1086 1102 </p> 1087 <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.1088 </p> 1089 <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 same1103 <p id="rfc.section.8.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. 1104 </p> 1105 <p id="rfc.section.8.p.9">If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same 1090 1106 Request-URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing 1091 1107 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. 1092 1108 </p> 1093 <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>1094 <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-shared1109 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="shared.and.non-shared.caches" href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></h1> 1110 <p id="rfc.section.9.p.1">For reasons of security and privacy, it is necessary to make a distinction between "shared" and "non-shared" caches. A non-shared 1095 1111 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 1096 1112 place certain constraints on the operation of shared caches in order to prevent loss of privacy or failure of access controls. 1097 1113 </p> 1098 <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>1099 <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.1114 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></h1> 1115 <p id="rfc.section.10.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 5</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. 1100 1116 A cache <em class="bcp14">MUST NOT</em> return a partial response using a status code of 200 (OK). 1101 1117 </p> 1102 <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>).1103 </p> 1104 <h1 id="rfc.section.1 0"><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>1105 <p id="rfc.section.1 0.p.1">Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any1118 <p id="rfc.section.10.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 16.2</a>). 1119 </p> 1120 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="side.effects.of.get.and.head" href="#side.effects.of.get.and.head">Side Effects of GET and HEAD</a></h1> 1121 <p id="rfc.section.11.p.1">Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any 1106 1122 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 1107 1123 expected to observe an origin server's explicit restrictions on caching. 1108 1124 </p> 1109 <p id="rfc.section.1 0.p.2">We note one exception to this rule: since some applications have traditionally used GET and HEAD requests with URLs containing1125 <p id="rfc.section.11.p.2">We note one exception to this rule: since some applications have traditionally used GET and HEAD requests with URLs containing 1110 1126 a query 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 1111 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 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for related information.1112 </p> 1113 <h1 id="rfc.section.1 1"><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>1114 <p id="rfc.section.1 1.p.1">The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries1127 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. 1128 </p> 1129 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></h1> 1130 <p id="rfc.section.12.p.1">The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries 1115 1131 to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what 1116 1132 the origin server would return for a new request on that resource. 1117 1133 </p> 1118 <p id="rfc.section.1 1.p.2">There is no way for HTTP to guarantee that all such cache entries are marked invalid. For example, the request that caused1134 <p id="rfc.section.12.p.2">There is no way for HTTP to guarantee that all such cache entries are marked invalid. For example, the request that caused 1119 1135 the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules 1120 1136 help reduce the likelihood of erroneous behavior. 1121 1137 </p> 1122 <p id="rfc.section.1 1.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from1138 <p id="rfc.section.12.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from 1123 1139 its storage, or will mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response 1124 1140 to a subsequent request. 1125 1141 </p> 1126 <p id="rfc.section.1 1.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-Location1142 <p id="rfc.section.12.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 1127 1143 headers (if present). These methods are: 1128 1144 </p> … … 1132 1148 <li>POST</li> 1133 1149 </ul> 1134 <p id="rfc.section.1 1.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 service1150 <p id="rfc.section.12.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 1135 1151 attacks. 1136 1152 </p> 1137 <p id="rfc.section.1 1.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.1138 </p> 1139 <h1 id="rfc.section.1 2"><a href="#rfc.section.12">12.</a> <a id="write-through.mandatory" href="#write-through.mandatory">Write-Through Mandatory</a></h1>1140 <p id="rfc.section.1 2.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 corresponding1153 <p id="rfc.section.12.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. 1154 </p> 1155 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="write-through.mandatory" href="#write-through.mandatory">Write-Through Mandatory</a></h1> 1156 <p id="rfc.section.13.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 1141 1157 response from the inbound server. This does not prevent a proxy cache from sending a 100 (Continue) response before the inbound 1142 1158 server has sent its final reply. 1143 1159 </p> 1144 <p id="rfc.section.1 2.p.2">The alternative (known as "write-back" or "copy-back" caching) is not allowed in HTTP/1.1, due to the difficulty of providing1160 <p id="rfc.section.13.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 1145 1161 consistent updates and the problems arising from server, cache, or network failure prior to write-back. 1146 1162 </p> 1147 <h1 id="rfc.section.1 3"><a href="#rfc.section.13">13.</a> <a id="cache.replacement" href="#cache.replacement">Cache Replacement</a></h1>1148 <p id="rfc.section.1 3.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 response1149 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.1163 <h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a id="cache.replacement" href="#cache.replacement">Cache Replacement</a></h1> 1164 <p id="rfc.section.14.p.1">If a new cacheable (see Sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">16.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">4.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">4.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">10</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 1165 to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section 7.3</a> apply. 1150 1166 </p> 1151 1167 <dl class="empty"> … … 1153 1169 </dd> 1154 1170 </dl> 1155 <h1 id="rfc.section.1 4"><a href="#rfc.section.14">14.</a> <a id="history.lists" href="#history.lists">History Lists</a></h1>1156 <p id="rfc.section.1 4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity1171 <h1 id="rfc.section.15"><a href="#rfc.section.15">15.</a> <a id="history.lists" href="#history.lists">History Lists</a></h1> 1172 <p id="rfc.section.15.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity 1157 1173 retrieved earlier in a session. 1158 1174 </p> 1159 <p id="rfc.section.1 4.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 show1175 <p id="rfc.section.15.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 1160 1176 exactly what the user saw at the time when the resource was retrieved. 1161 1177 </p> 1162 <p id="rfc.section.1 4.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history1178 <p id="rfc.section.15.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 1163 1179 documents. 1164 1180 </p> 1165 <p id="rfc.section.1 4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>1181 <p id="rfc.section.15.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p> 1166 1182 <dl class="empty"> 1167 1183 <dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors … … 1173 1189 </dd> 1174 1190 </dl> 1175 <h1 id="rfc.section.1 5"><a href="#rfc.section.15">15.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>1176 <p id="rfc.section.1 5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>1177 <p id="rfc.section.1 5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1191 <h1 id="rfc.section.16"><a href="#rfc.section.16">16.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1192 <p id="rfc.section.16.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> 1193 <p id="rfc.section.16.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 1178 1194 receives the entity. 1179 1195 </p> 1180 1196 <div id="rfc.iref.a.2"></div> 1181 1197 <div id="rfc.iref.h.2"></div> 1182 <h2 id="rfc.section.1 5.1"><a href="#rfc.section.15.1">15.1</a> <a id="header.age" href="#header.age">Age</a></h2>1183 <p id="rfc.section.1 5.1.p.1">The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation)1198 <h2 id="rfc.section.16.1"><a href="#rfc.section.16.1">16.1</a> <a id="header.age" href="#header.age">Age</a></h2> 1199 <p id="rfc.section.16.1.p.1">The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) 1184 1200 was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. Age values 1185 are calculated as specified in <a href="#age.calculations" title="Age Calculations">Section 3.3</a>.1186 </p> 1187 <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-value1201 are calculated as specified in <a href="#age.calculations" title="Age Calculations">Section 4.3</a>. 1202 </p> 1203 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> Age = "Age" ":" age-value 1188 1204 age-value = delta-seconds 1189 </pre><p id="rfc.section.1 5.1.p.3">Age values are non-negative decimal integers, representing time in seconds.</p>1190 <div id="rfc.figure.u.1 0"></div><pre class="inline"><span id="rfc.iref.g.3"></span> delta-seconds = 1*DIGIT1191 </pre><p id="rfc.section.1 5.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,1205 </pre><p id="rfc.section.16.1.p.3">Age values are non-negative decimal integers, representing time in seconds.</p> 1206 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.3"></span> delta-seconds = 1*DIGIT 1207 </pre><p id="rfc.section.16.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, 1192 1208 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. 1193 1209 </p> 1194 1210 <div id="rfc.iref.c.3"></div> 1195 1211 <div id="rfc.iref.h.3"></div> 1196 <h2 id="rfc.section.1 5.2"><a href="#rfc.section.15.2">15.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>1197 <p id="rfc.section.1 5.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 prevent1212 <h2 id="rfc.section.16.2"><a href="#rfc.section.16.2">16.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> 1213 <p id="rfc.section.16.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 1198 1214 caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. 1199 1215 Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive … … 1201 1217 </p> 1202 1218 <dl class="empty"> 1203 <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 1 5.4</a>).1204 </dd> 1205 </dl> 1206 <p id="rfc.section.1 5.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 directives1219 <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 16.4</a>). 1220 </dd> 1221 </dl> 1222 <p id="rfc.section.16.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 1207 1223 might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for 1208 1224 a specific cache. 1209 1225 </p> 1210 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> Cache-Control = "Cache-Control" ":" 1#cache-directive1226 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> Cache-Control = "Cache-Control" ":" 1#cache-directive 1211 1227 1212 1228 cache-directive = cache-request-directive … … 1214 1230 1215 1231 cache-request-directive = 1216 "no-cache" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 1 5.2.1</a>1217 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 1 5.2.2</a>1218 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 1 5.2.3</a>, <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">15.2.4</a>1219 | "max-stale" [ "=" delta-seconds ] ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 1 5.2.3</a>1220 | "min-fresh" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 1 5.2.3</a>1221 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 1 5.2.5</a>1222 | "only-if-cached" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 1 5.2.4</a>1223 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 1 5.2.6</a>1232 "no-cache" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 16.2.1</a> 1233 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 16.2.2</a> 1234 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 16.2.3</a>, <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">16.2.4</a> 1235 | "max-stale" [ "=" delta-seconds ] ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 16.2.3</a> 1236 | "min-fresh" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 16.2.3</a> 1237 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 16.2.5</a> 1238 | "only-if-cached" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 16.2.4</a> 1239 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 16.2.6</a> 1224 1240 1225 1241 cache-response-directive = 1226 "public" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 1 5.2.1</a>1227 | "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; <a href="#what.is.cacheable" title="What is Cacheable">Section 1 5.2.1</a>1228 | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]; <a href="#what.is.cacheable" title="What is Cacheable">Section 1 5.2.1</a>1229 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 1 5.2.2</a>1230 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 1 5.2.5</a>1231 | "must-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 1 5.2.4</a>1232 | "proxy-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 1 5.2.4</a>1233 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 1 5.2.3</a>1234 | "s-maxage" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 1 5.2.3</a>1235 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 1 5.2.6</a>1242 "public" ; <a href="#what.is.cacheable" title="What is Cacheable">Section 16.2.1</a> 1243 | "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; <a href="#what.is.cacheable" title="What is Cacheable">Section 16.2.1</a> 1244 | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]; <a href="#what.is.cacheable" title="What is Cacheable">Section 16.2.1</a> 1245 | "no-store" ; <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">Section 16.2.2</a> 1246 | "no-transform" ; <a href="#no-transform.directive" title="No-Transform Directive">Section 16.2.5</a> 1247 | "must-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 16.2.4</a> 1248 | "proxy-revalidate" ; <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 16.2.4</a> 1249 | "max-age" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 16.2.3</a> 1250 | "s-maxage" "=" delta-seconds ; <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 16.2.3</a> 1251 | cache-extension ; <a href="#cache.control.extensions" title="Cache Control Extensions">Section 16.2.6</a> 1236 1252 1237 1253 cache-extension = token [ "=" ( token | quoted-string ) ] 1238 </pre><p id="rfc.section.1 5.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When1254 </pre><p id="rfc.section.16.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When 1239 1255 such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest 1240 1256 of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply 1241 1257 these directives to header fields not defined in HTTP/1.1. 1242 1258 </p> 1243 <p id="rfc.section.1 5.2.p.5">The cache-control directives can be broken down into these general categories: </p>1259 <p id="rfc.section.16.2.p.5">The cache-control directives can be broken down into these general categories: </p> 1244 1260 <ul> 1245 1261 <li>Restrictions on what are cacheable; these may only be imposed by the origin server.</li> … … 1250 1266 <li>Extensions to the caching system.</li> 1251 1267 </ul> 1252 <h3 id="rfc.section.1 5.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>1253 <p id="rfc.section.1 5.2.1.p.1">By default, a response is cacheable if the requirements of the request method, request header fields, and the response status1254 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 override1268 <h3 id="rfc.section.16.2.1"><a href="#rfc.section.16.2.1">16.2.1</a> <a id="what.is.cacheable" href="#what.is.cacheable">What is Cacheable</a></h3> 1269 <p id="rfc.section.16.2.1.p.1">By default, a response is cacheable if the requirements of the request method, request header fields, and the response status 1270 indicate that it is cacheable. <a href="#response.cacheability" title="Response Cacheability">Section 6</a> summarizes these defaults for cacheability. The following Cache-Control response directives allow an origin server to override 1255 1271 the default cacheability of a response: 1256 1272 </p> 1257 <p id="rfc.section.1 5.2.1.p.2"> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.p.1"></span> public1273 <p id="rfc.section.16.2.1.p.2"> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.p.1"></span> public 1258 1274 </p> 1259 1275 <dl class="empty"> 1260 1276 <dd>Indicates that the response <em class="bcp14">MAY</em> be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also 1261 Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.)1262 </dd> 1263 </dl> 1264 <p id="rfc.section.1 5.2.1.p.3"> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.p.2"></span> private1277 Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.) 1278 </dd> 1279 </dl> 1280 <p id="rfc.section.16.2.1.p.3"> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.p.2"></span> private 1265 1281 </p> 1266 1282 <dl class="empty"> … … 1272 1288 </dd> 1273 1289 </dl> 1274 <p id="rfc.section.1 5.2.1.p.4"> <span id="rfc.iref.c.6"></span> <span id="rfc.iref.n.1"></span> no-cache1290 <p id="rfc.section.16.2.1.p.4"> <span id="rfc.iref.c.6"></span> <span id="rfc.iref.n.1"></span> no-cache 1275 1291 </p> 1276 1292 <dl class="empty"> … … 1286 1302 </dd> 1287 1303 </dl> 1288 <h3 id="rfc.section.1 5.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>1289 <p id="rfc.section.1 5.2.2.p.1"> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.n.2"></span> no-store1304 <h3 id="rfc.section.16.2.2"><a href="#rfc.section.16.2.2">16.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> 1305 <p id="rfc.section.16.2.2.p.1"> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.n.2"></span> no-store 1290 1306 </p> 1291 1307 <dl class="empty"> … … 1304 1320 </dd> 1305 1321 </dl> 1306 <h3 id="rfc.section.1 5.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>1307 <p id="rfc.section.1 5.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,1322 <h3 id="rfc.section.16.2.3"><a href="#rfc.section.16.2.3">16.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> 1323 <p id="rfc.section.16.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 16.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, 1308 1324 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 1309 1325 that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, 1310 1326 more restrictive cache directive is also present. 1311 1327 </p> 1312 <p id="rfc.section.1 5.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,1328 <p id="rfc.section.16.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, 1313 1329 even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer 1314 1330 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 1315 1331 improperly calculate ages or expiration times, perhaps due to desynchronized clocks. 1316 1332 </p> 1317 <p id="rfc.section.1 5.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 being1333 <p id="rfc.section.16.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 1318 1334 equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response 1319 1335 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. … … 1326 1342 </dd> 1327 1343 </dl> 1328 <p id="rfc.section.1 5.2.3.p.4"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.s.3"></span> s-maxage1344 <p id="rfc.section.16.2.3.p.4"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.s.3"></span> s-maxage 1329 1345 </p> 1330 1346 <dl class="empty"> 1331 1347 <dd>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified 1332 1348 by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage 1333 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 1 5.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 first1349 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 16.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 1334 1350 revalidating it with the origin server. The s-maxage directive is always ignored by a private cache. 1335 1351 </dd> 1336 1352 </dl> 1337 <p id="rfc.section.1 5.2.3.p.5">Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin1353 <p id="rfc.section.16.2.3.p.5">Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin 1338 1354 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 1339 1355 caches do not observe the max-age directive. 1340 1356 </p> 1341 <p id="rfc.section.1 5.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:1342 </p> 1343 <p id="rfc.section.1 5.2.3.p.7"> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.1"></span> max-age1357 <p id="rfc.section.16.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: 1358 </p> 1359 <p id="rfc.section.16.2.3.p.7"> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.1"></span> max-age 1344 1360 </p> 1345 1361 <dl class="empty"> … … 1348 1364 </dd> 1349 1365 </dl> 1350 <p id="rfc.section.1 5.2.3.p.8"> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.m.2"></span> min-fresh1366 <p id="rfc.section.16.2.3.p.8"> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.m.2"></span> min-fresh 1351 1367 </p> 1352 1368 <dl class="empty"> … … 1356 1372 </dd> 1357 1373 </dl> 1358 <p id="rfc.section.1 5.2.3.p.9"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.m.3"></span> max-stale1374 <p id="rfc.section.16.2.3.p.9"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.m.3"></span> max-stale 1359 1375 </p> 1360 1376 <dl class="empty"> … … 1364 1380 </dd> 1365 1381 </dl> 1366 <p id="rfc.section.1 5.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 configured1382 <p id="rfc.section.16.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 1367 1383 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). 1368 1384 </p> 1369 <p id="rfc.section.1 5.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 requirements1385 <p id="rfc.section.16.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 1370 1386 concerning cache validation (e.g., a "must-revalidate" cache-control directive). 1371 1387 </p> 1372 <p id="rfc.section.1 5.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 determining1388 <p id="rfc.section.16.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 1373 1389 the freshness of the cached entry for that request. 1374 1390 </p> 1375 <h3 id="rfc.section.1 5.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>1376 <p id="rfc.section.1 5.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 not1391 <h3 id="rfc.section.16.2.4"><a href="#rfc.section.16.2.4">16.2.4</a> <a id="cache.revalidation.and.reload.controls" href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></h3> 1392 <p id="rfc.section.16.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 1377 1393 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 1378 1394 revalidation might be necessary if either the cache or the origin server has overestimated the expiration time of the cached 1379 1395 response. End-to-end reload may be necessary if the cache entry has become corrupted for some reason. 1380 1396 </p> 1381 <p id="rfc.section.1 5.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 we1397 <p id="rfc.section.16.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 1382 1398 call it "unspecified end-to-end revalidation", or when the client does have a local cached copy, in which case we call it 1383 1399 "specific end-to-end revalidation." 1384 1400 </p> 1385 <p id="rfc.section.1 5.2.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p>1386 <p id="rfc.section.1 5.2.4.p.4">End-to-end reload </p>1401 <p id="rfc.section.16.2.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p> 1402 <p id="rfc.section.16.2.4.p.4">End-to-end reload </p> 1387 1403 <dl class="empty"> 1388 1404 <dd>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". … … 1390 1406 </dd> 1391 1407 </dl> 1392 <p id="rfc.section.1 5.2.4.p.5">Specific end-to-end revalidation </p>1408 <p id="rfc.section.16.2.4.p.5">Specific end-to-end revalidation </p> 1393 1409 <dl class="empty"> 1394 1410 <dd>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to … … 1397 1413 </dd> 1398 1414 </dl> 1399 <p id="rfc.section.1 5.2.4.p.6">Unspecified end-to-end revalidation </p>1415 <p id="rfc.section.16.2.4.p.6">Unspecified end-to-end revalidation </p> 1400 1416 <dl class="empty"> 1401 1417 <dd>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate … … 1405 1421 </dd> 1406 1422 </dl> 1407 <p id="rfc.section.1 5.2.4.p.7"> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.m.4"></span> max-age1423 <p id="rfc.section.16.2.4.p.7"> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.m.4"></span> max-age 1408 1424 </p> 1409 1425 <dl class="empty"> … … 1422 1438 </dd> 1423 1439 </dl> 1424 <p id="rfc.section.1 5.2.4.p.8"> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.o.1"></span> only-if-cached1440 <p id="rfc.section.16.2.4.p.8"> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.o.1"></span> only-if-cached 1425 1441 </p> 1426 1442 <dl class="empty"> … … 1432 1448 </dd> 1433 1449 </dl> 1434 <p id="rfc.section.1 5.2.4.p.9"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.m.5"></span> must-revalidate1450 <p id="rfc.section.16.2.4.p.9"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.m.5"></span> must-revalidate 1435 1451 </p> 1436 1452 <dl class="empty"> … … 1450 1466 </dd> 1451 1467 </dl> 1452 <p id="rfc.section.1 5.2.4.p.10"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.3"></span> proxy-revalidate1468 <p id="rfc.section.16.2.4.p.10"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.3"></span> proxy-revalidate 1453 1469 </p> 1454 1470 <dl class="empty"> … … 1461 1477 </dd> 1462 1478 </dl> 1463 <h3 id="rfc.section.1 5.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>1464 <p id="rfc.section.1 5.2.5.p.1"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.3"></span> no-transform1479 <h3 id="rfc.section.16.2.5"><a href="#rfc.section.16.2.5">16.2.5</a> <a id="no-transform.directive" href="#no-transform.directive">No-Transform Directive</a></h3> 1480 <p id="rfc.section.16.2.5.p.1"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.3"></span> no-transform 1465 1481 </p> 1466 1482 <dl class="empty"> … … 1473 1489 authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body. 1474 1490 </dd> 1475 <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.1476 </dd> 1477 </dl> 1478 <h3 id="rfc.section.1 5.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>1479 <p id="rfc.section.1 5.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 optional1491 <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 7.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. 1492 </dd> 1493 </dl> 1494 <h3 id="rfc.section.16.2.6"><a href="#rfc.section.16.2.6">16.2.6</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> 1495 <p id="rfc.section.16.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 1480 1496 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 1481 1497 to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications … … 1484 1500 way, extensions to the cache-control directives can be made without requiring changes to the base protocol. 1485 1501 </p> 1486 <p id="rfc.section.1 5.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,1502 <p id="rfc.section.16.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, 1487 1503 obeying certain extensions, and ignoring all directives that it does not understand. 1488 1504 </p> 1489 <p id="rfc.section.1 5.2.6.p.3">For example, consider a hypothetical new response directive called community which acts as a modifier to the private directive.1505 <p id="rfc.section.16.2.6.p.3">For example, consider a hypothetical new response directive called community which acts as a modifier to the private directive. 1490 1506 We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members 1491 1507 of the community named within its value may cache the response. An origin server wishing to allow the UCI community to use 1492 1508 an otherwise private response in their shared cache(s) could do so by including 1493 1509 </p> 1494 <div id="rfc.figure.u.1 2"></div><pre class="text"> Cache-Control: private, community="UCI"1495 </pre><p id="rfc.section.1 5.2.6.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since1510 <div id="rfc.figure.u.15"></div><pre class="text"> Cache-Control: private, community="UCI" 1511 </pre><p id="rfc.section.16.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 1496 1512 it will also see and understand the private directive and thus default to the safe behavior. 1497 1513 </p> 1498 <p id="rfc.section.1 5.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 standard1514 <p id="rfc.section.16.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 1499 1515 directives (or the response's default cacheability) such that the cache behavior will remain minimally correct even if the 1500 1516 cache does not understand the extension(s). … … 1502 1518 <div id="rfc.iref.e.2"></div> 1503 1519 <div id="rfc.iref.h.4"></div> 1504 <h2 id="rfc.section.1 5.3"><a href="#rfc.section.15.3">15.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2>1505 <p id="rfc.section.1 5.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may1520 <h2 id="rfc.section.16.3"><a href="#rfc.section.16.3">16.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2> 1521 <p id="rfc.section.16.3.p.1">The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may 1506 1522 not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin 1507 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.1508 </p> 1509 <p id="rfc.section.1 5.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after1523 server (or with an intermediate cache that has a fresh copy of the entity). See <a href="#expiration.model" title="Expiration Model">Section 4</a> for further discussion of the expiration model. 1524 </p> 1525 <p id="rfc.section.16.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 1510 1526 that time. 1511 1527 </p> 1512 <p id="rfc.section.1 5.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.1513 </p> 1514 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Expires = "Expires" ":" HTTP-date1515 </pre><p id="rfc.section.1 5.3.p.5">An example of its use is</p>1516 <div id="rfc.figure.u.1 4"></div><pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT1517 </pre><p id="rfc.section.1 5.3.p.7"> </p>1518 <dl class="empty"> 1519 <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 1 5.2.3</a>), that directive overrides the Expires field.1520 </dd> 1521 </dl> 1522 <p id="rfc.section.1 5.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").1523 </p> 1524 <p id="rfc.section.1 5.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. (See1525 the rules for expiration calculations in <a href="#expiration.calculations" title="Expiration Calculations">Section 3.4</a>.)1526 </p> 1527 <p id="rfc.section.1 5.3.p.10">To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response1528 <p id="rfc.section.16.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.18"><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. 1529 </p> 1530 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Expires = "Expires" ":" HTTP-date 1531 </pre><p id="rfc.section.16.3.p.5">An example of its use is</p> 1532 <div id="rfc.figure.u.17"></div><pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1533 </pre><p id="rfc.section.16.3.p.7"> </p> 1534 <dl class="empty"> 1535 <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 16.2.3</a>), that directive overrides the Expires field. 1536 </dd> 1537 </dl> 1538 <p id="rfc.section.16.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"). 1539 </p> 1540 <p id="rfc.section.16.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 1541 the rules for expiration calculations in <a href="#expiration.calculations" title="Expiration Calculations">Section 4.4</a>.) 1542 </p> 1543 <p id="rfc.section.16.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 1528 1544 is sent. HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future. 1529 1545 </p> 1530 <p id="rfc.section.1 5.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 by1546 <p id="rfc.section.16.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 1531 1547 default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field 1532 (<a href="#header.cache-control" id="rfc.xref.header.cache-control.9" title="Cache-Control">Section 1 5.2</a>).1548 (<a href="#header.cache-control" id="rfc.xref.header.cache-control.9" title="Cache-Control">Section 16.2</a>). 1533 1549 </p> 1534 1550 <div id="rfc.iref.p.4"></div> 1535 1551 <div id="rfc.iref.h.5"></div> 1536 <h2 id="rfc.section.1 5.4"><a href="#rfc.section.15.4">15.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2>1537 <p id="rfc.section.1 5.4.p.1">The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along1552 <h2 id="rfc.section.16.4"><a href="#rfc.section.16.4">16.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> 1553 <p id="rfc.section.16.4.p.1">The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along 1538 1554 the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some 1539 1555 systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives. 1540 1556 </p> 1541 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> Pragma = "Pragma" ":" 1#pragma-directive1557 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> Pragma = "Pragma" ":" 1#pragma-directive 1542 1558 pragma-directive = "no-cache" | extension-pragma 1543 1559 extension-pragma = token [ "=" ( token | quoted-string ) ] 1544 </pre><p id="rfc.section.1 5.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 directive1545 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 1 5.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.1546 </p> 1547 <p id="rfc.section.1 5.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 directives1560 </pre><p id="rfc.section.16.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 1561 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 16.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. 1562 </p> 1563 <p id="rfc.section.16.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 1548 1564 might be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific 1549 1565 recipient; however, any pragma directive not relevant to a recipient <em class="bcp14">SHOULD</em> be ignored by that recipient. 1550 1566 </p> 1551 <p id="rfc.section.1 5.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 in1567 <p id="rfc.section.16.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 1552 1568 HTTP. 1553 1569 </p> … … 1559 1575 <div id="rfc.iref.v.2"></div> 1560 1576 <div id="rfc.iref.h.6"></div> 1561 <h2 id="rfc.section.1 5.5"><a href="#rfc.section.15.5">15.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2>1562 <p id="rfc.section.1 5.5.p.1">The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether1577 <h2 id="rfc.section.16.5"><a href="#rfc.section.16.5">16.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> 1578 <p id="rfc.section.16.5.p.1">The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether 1563 1579 a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, 1564 1580 the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value 1565 1581 of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the 1566 appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 7</a> for use of the Vary header field by caches.1567 </p> 1568 <div id="rfc.figure.u.1 6"></div><pre class="inline"><span id="rfc.iref.g.13"></span> Vary = "Vary" ":" ( "*" | 1#field-name )1569 </pre><p id="rfc.section.1 5.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 cache1582 appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 8</a> for use of the Vary header field by caches. 1583 </p> 1584 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.13"></span> Vary = "Vary" ":" ( "*" | 1#field-name ) 1585 </pre><p id="rfc.section.16.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 1570 1586 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that 1571 1587 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 1572 1588 the user agent with useful information about the dimensions over which the response varies at the time of the response. 1573 1589 </p> 1574 <p id="rfc.section.1 5.5.p.4">A Vary field value consisting of a list of field-names signals that the representation selected for the response is based1590 <p id="rfc.section.16.5.p.4">A Vary field value consisting of a list of field-names signals that the representation selected for the response is based 1575 1591 on a selection algorithm which considers ONLY the listed request-header field values in selecting the most appropriate representation. 1576 1592 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 1577 1593 of time for which the response is fresh. 1578 1594 </p> 1579 <p id="rfc.section.1 5.5.p.5">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names1595 <p id="rfc.section.16.5.p.5">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names 1580 1596 are case-insensitive. 1581 1597 </p> 1582 <p id="rfc.section.1 5.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address1598 <p id="rfc.section.16.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address 1583 1599 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. 1584 1600 </p> 1585 1601 <div id="rfc.iref.w.1"></div> 1586 1602 <div id="rfc.iref.h.7"></div> 1587 <h2 id="rfc.section.1 5.6"><a href="#rfc.section.15.6">15.6</a> <a id="header.warning" href="#header.warning">Warning</a></h2>1588 <p id="rfc.section.1 5.6.p.1">The Warning general-header field is used to carry additional information about the status or transformation of a message which1603 <h2 id="rfc.section.16.6"><a href="#rfc.section.16.6">16.6</a> <a id="header.warning" href="#header.warning">Warning</a></h2> 1604 <p id="rfc.section.16.6.p.1">The Warning general-header field is used to carry additional information about the status or transformation of a message which 1589 1605 might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency 1590 1606 from caching operations or transformations applied to the entity body of the message. 1591 1607 </p> 1592 <p id="rfc.section.1 5.6.p.2">Warning headers are sent with responses using:</p>1593 <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-value1608 <p id="rfc.section.16.6.p.2">Warning headers are sent with responses using:</p> 1609 <div id="rfc.figure.u.20"></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 1594 1610 1595 1611 warning-value = warn-code SP warn-agent SP warn-text … … 1602 1618 warn-text = quoted-string 1603 1619 warn-date = DQUOTE HTTP-date DQUOTE 1604 </pre><p id="rfc.section.1 5.6.p.4">A response <em class="bcp14">MAY</em> carry more than one Warning header.1605 </p> 1606 <p id="rfc.section.1 5.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.1620 </pre><p id="rfc.section.16.6.p.4">A response <em class="bcp14">MAY</em> carry more than one Warning header. 1621 </p> 1622 <p id="rfc.section.16.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. 1607 1623 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 1608 1624 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>). 1609 1625 </p> 1610 <p id="rfc.section.1 5.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>.1611 </p> 1612 <p id="rfc.section.1 5.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can1626 <p id="rfc.section.16.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>. 1627 </p> 1628 <p id="rfc.section.16.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can 1613 1629 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 1614 1630 attached to the most recent relevant response. 1615 1631 </p> 1616 <p id="rfc.section.1 5.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,1632 <p id="rfc.section.16.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, 1617 1633 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: 1618 1634 </p> … … 1623 1639 </li> 1624 1640 </ul> 1625 <p id="rfc.section.1 5.6.p.9">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind.1626 </p> 1627 <p id="rfc.section.1 5.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>.1628 </p> 1629 <p id="rfc.section.1 5.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 its1641 <p id="rfc.section.16.6.p.9">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. 1642 </p> 1643 <p id="rfc.section.16.6.p.10">Requirements for the behavior of caches with respect to Warnings are stated in <a href="#warnings" title="Warnings">Section 3.2</a>. 1644 </p> 1645 <p id="rfc.section.16.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 1630 1646 meaning. 1631 1647 </p> 1632 <p id="rfc.section.1 5.6.p.12">110 Response is stale </p>1648 <p id="rfc.section.16.6.p.12">110 Response is stale </p> 1633 1649 <dl class="empty"> 1634 1650 <dd> <em class="bcp14">MUST</em> be included whenever the returned response is stale. 1635 1651 </dd> 1636 1652 </dl> 1637 <p id="rfc.section.1 5.6.p.13">111 Revalidation failed </p>1653 <p id="rfc.section.16.6.p.13">111 Revalidation failed </p> 1638 1654 <dl class="empty"> 1639 1655 <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 … … 1641 1657 </dd> 1642 1658 </dl> 1643 <p id="rfc.section.1 5.6.p.14">112 Disconnected operation </p>1659 <p id="rfc.section.16.6.p.14">112 Disconnected operation </p> 1644 1660 <dl class="empty"> 1645 1661 <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. 1646 1662 </dd> 1647 1663 </dl> 1648 <p id="rfc.section.1 5.6.p.15">113 Heuristic expiration </p>1664 <p id="rfc.section.16.6.p.15">113 Heuristic expiration </p> 1649 1665 <dl class="empty"> 1650 1666 <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 … … 1652 1668 </dd> 1653 1669 </dl> 1654 <p id="rfc.section.1 5.6.p.16">199 Miscellaneous warning </p>1670 <p id="rfc.section.16.6.p.16">199 Miscellaneous warning </p> 1655 1671 <dl class="empty"> 1656 1672 <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. 1657 1673 </dd> 1658 1674 </dl> 1659 <p id="rfc.section.1 5.6.p.17">214 Transformation applied </p>1675 <p id="rfc.section.16.6.p.17">214 Transformation applied </p> 1660 1676 <dl class="empty"> 1661 1677 <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 … … 1664 1680 </dd> 1665 1681 </dl> 1666 <p id="rfc.section.1 5.6.p.18">299 Miscellaneous persistent warning </p>1682 <p id="rfc.section.16.6.p.18">299 Miscellaneous persistent warning </p> 1667 1683 <dl class="empty"> 1668 1684 <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. 1669 1685 </dd> 1670 1686 </dl> 1671 <p id="rfc.section.1 5.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.1672 </p> 1673 <p id="rfc.section.1 5.6.p.20">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from1687 <p id="rfc.section.16.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. 1688 </p> 1689 <p id="rfc.section.16.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 1674 1690 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 1675 1691 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. 1676 1692 </p> 1677 <h1 id="rfc.section.1 6"><a href="#rfc.section.16">16.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>1678 <p id="rfc.section.1 6.p.1"> <span class="comment">[rfc.comment.1: TBD.]</span>1679 </p> 1680 <h1 id="rfc.section.1 7"><a href="#rfc.section.17">17.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1681 <p id="rfc.section.1 7.p.1">Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target1693 <h1 id="rfc.section.17"><a href="#rfc.section.17">17.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1694 <p id="rfc.section.17.p.1"> <span class="comment">[rfc.comment.1: TBD.]</span> 1695 </p> 1696 <h1 id="rfc.section.18"><a href="#rfc.section.18">18.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1697 <p id="rfc.section.18.p.1">Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target 1682 1698 for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal 1683 1699 information long after a user believes that the information has been removed from the network. Therefore, cache contents should 1684 1700 be protected as sensitive information. 1685 1701 </p> 1686 <h1 id="rfc.section.1 8"><a href="#rfc.section.18">18.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>1687 <p id="rfc.section.1 8.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including:1702 <h1 id="rfc.section.19"><a href="#rfc.section.19">19.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1703 <p id="rfc.section.19.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including: 1688 1704 Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter. 1689 1705 </p> 1690 <h1 id="rfc.references"><a id="rfc.section. 19" href="#rfc.section.19">19.</a> References1706 <h1 id="rfc.references"><a id="rfc.section.20" href="#rfc.section.20">20.</a> References 1691 1707 </h1> 1692 <h2 id="rfc.references.1"><a href="#rfc.section. 19.1" id="rfc.section.19.1">19.1</a> Normative References1708 <h2 id="rfc.references.1"><a href="#rfc.section.20.1" id="rfc.section.20.1">20.1</a> Normative References 1693 1709 </h2> 1694 1710 <table summary="Normative References"> … … 1741 1757 </tr> 1742 1758 </table> 1743 <h2 id="rfc.references.2"><a href="#rfc.section. 19.2" id="rfc.section.19.2">19.2</a> Informative References1759 <h2 id="rfc.references.2"><a href="#rfc.section.20.2" id="rfc.section.20.2">20.2</a> Informative References 1744 1760 </h2> 1745 1761 <table summary="Informative References"> … … 1773 1789 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1774 1790 <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> 1775 <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>)1791 <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">6</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.11" title="Cache-Control">16.2</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">16.2.3</a>) 1776 1792 </p> 1777 1793 <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 1778 1794 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1779 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>)1780 </p> 1781 <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>)1795 computed. (<a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 7.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.19"><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>) 1796 </p> 1797 <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 7.2</a>) 1782 1798 </p> 1783 1799 <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 1784 needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Headers">Section 6.3</a>)1785 </p> 1786 <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 1 5.2.3</a>)1787 </p> 1788 <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.1800 needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Headers">Section 7.3</a>) 1801 </p> 1802 <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 16.2.3</a>) 1803 </p> 1804 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#warnings" title="Warnings">3.2</a>, <a href="#expiration.calculations" title="Expiration Calculations">4.4</a>, <a href="#non-modifiable.headers" title="Non-modifiable Headers">7.2</a>, <a href="#combining.headers" title="Combining Headers">7.3</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">16.2.3</a>, and <a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">16.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 1789 1805 </p> 1790 1806 <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> 1791 <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 1 1</a>)1807 <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 12</a>) 1792 1808 </p> 1793 1809 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) … … 1836 1852 <li>Get rid of duplicate BNF rule names ("host" -> "uri-host") (work in progress on <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>) 1837 1853 </li> 1854 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 1838 1855 </ul> 1839 1856 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 1871 1888 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 1872 1889 <li class="indline1">age <a class="iref" href="#rfc.iref.a.1">1.2</a></li> 1873 <li class="indline1">Age header <a class="iref" href="#rfc.iref.a.2"><b>1 5.1</b></a></li>1890 <li class="indline1">Age header <a class="iref" href="#rfc.iref.a.2"><b>16.1</b></a></li> 1874 1891 </ul> 1875 1892 </li> … … 1878 1895 <li class="indline1">Cache Directives 1879 1896 <ul class="ind"> 1880 <li class="indline1">max-age <a class="iref" href="#rfc.iref.c.9"><b>1 5.2.3</b></a>, <a class="iref" href="#rfc.iref.c.12"><b>15.2.4</b></a></li>1881 <li class="indline1">max-stale <a class="iref" href="#rfc.iref.c.11"><b>1 5.2.3</b></a></li>1882 <li class="indline1">min-fresh <a class="iref" href="#rfc.iref.c.10"><b>1 5.2.3</b></a></li>1883 <li class="indline1">must-revalidate <a class="iref" href="#rfc.iref.c.14"><b>1 5.2.4</b></a></li>1884 <li class="indline1">no-cache <a class="iref" href="#rfc.iref.c.6"><b>1 5.2.1</b></a></li>1885 <li class="indline1">no-store <a class="iref" href="#rfc.iref.c.7"><b>1 5.2.2</b></a></li>1886 <li class="indline1">no-transform <a class="iref" href="#rfc.iref.c.16"><b>1 5.2.5</b></a></li>1887 <li class="indline1">only-if-cached <a class="iref" href="#rfc.iref.c.13"><b>1 5.2.4</b></a></li>1888 <li class="indline1">private <a class="iref" href="#rfc.iref.c.5"><b>1 5.2.1</b></a></li>1889 <li class="indline1">proxy-revalidate <a class="iref" href="#rfc.iref.c.15"><b>1 5.2.4</b></a></li>1890 <li class="indline1">public <a class="iref" href="#rfc.iref.c.4"><b>1 5.2.1</b></a></li>1891 <li class="indline1">s-maxage <a class="iref" href="#rfc.iref.c.8"><b>1 5.2.3</b></a></li>1897 <li class="indline1">max-age <a class="iref" href="#rfc.iref.c.9"><b>16.2.3</b></a>, <a class="iref" href="#rfc.iref.c.12"><b>16.2.4</b></a></li> 1898 <li class="indline1">max-stale <a class="iref" href="#rfc.iref.c.11"><b>16.2.3</b></a></li> 1899 <li class="indline1">min-fresh <a class="iref" href="#rfc.iref.c.10"><b>16.2.3</b></a></li> 1900 <li class="indline1">must-revalidate <a class="iref" href="#rfc.iref.c.14"><b>16.2.4</b></a></li> 1901 <li class="indline1">no-cache <a class="iref" href="#rfc.iref.c.6"><b>16.2.1</b></a></li> 1902 <li class="indline1">no-store <a class="iref" href="#rfc.iref.c.7"><b>16.2.2</b></a></li> 1903 <li class="indline1">no-transform <a class="iref" href="#rfc.iref.c.16"><b>16.2.5</b></a></li> 1904 <li class="indline1">only-if-cached <a class="iref" href="#rfc.iref.c.13"><b>16.2.4</b></a></li> 1905 <li class="indline1">private <a class="iref" href="#rfc.iref.c.5"><b>16.2.1</b></a></li> 1906 <li class="indline1">proxy-revalidate <a class="iref" href="#rfc.iref.c.15"><b>16.2.4</b></a></li> 1907 <li class="indline1">public <a class="iref" href="#rfc.iref.c.4"><b>16.2.1</b></a></li> 1908 <li class="indline1">s-maxage <a class="iref" href="#rfc.iref.c.8"><b>16.2.3</b></a></li> 1892 1909 </ul> 1893 1910 </li> 1894 <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>1911 <li class="indline1">Cache-Control header <a class="iref" href="#rfc.xref.header.cache-control.1">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">3.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">4.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">4.5</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">6</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">6</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">10</a>, <a class="iref" href="#rfc.iref.c.3"><b>16.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.9">16.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.10">16.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.11">A.1</a></li> 1895 1912 <li class="indline1">cacheable <a class="iref" href="#rfc.iref.c.2">1.2</a></li> 1896 1913 </ul> 1897 1914 </li> 1898 1915 <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"> 1899 <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>1916 <li class="indline1">Expires header <a class="iref" href="#rfc.xref.header.expires.1">6</a>, <a class="iref" href="#rfc.xref.header.expires.2">16.2.3</a>, <a class="iref" href="#rfc.iref.e.2"><b>16.3</b></a></li> 1900 1917 <li class="indline1">explicit expiration time <a class="iref" href="#rfc.iref.e.1">1.2</a></li> 1901 1918 </ul> … … 1910 1927 <li class="indline1"><tt>Grammar</tt> 1911 1928 <ul class="ind"> 1912 <li class="indline1"><tt>Age</tt> <a class="iref" href="#rfc.iref.g.1"><b>1 5.1</b></a></li>1913 <li class="indline1"><tt>age-value</tt> <a class="iref" href="#rfc.iref.g.2"><b>1 5.1</b></a></li>1914 <li class="indline1"><tt>Cache-Control</tt> <a class="iref" href="#rfc.iref.g.4"><b>1 5.2</b></a></li>1915 <li class="indline1"><tt>cache-directive</tt> <a class="iref" href="#rfc.iref.g.5"><b>1 5.2</b></a></li>1916 <li class="indline1"><tt>cache-extension</tt> <a class="iref" href="#rfc.iref.g.8"><b>1 5.2</b></a></li>1917 <li class="indline1"><tt>cache-request-directive</tt> <a class="iref" href="#rfc.iref.g.6"><b>1 5.2</b></a></li>1918 <li class="indline1"><tt>cache-response-directive</tt> <a class="iref" href="#rfc.iref.g.7"><b>1 5.2</b></a></li>1919 <li class="indline1"><tt>delta-seconds</tt> <a class="iref" href="#rfc.iref.g.3"><b>1 5.1</b></a></li>1920 <li class="indline1"><tt>Expires</tt> <a class="iref" href="#rfc.iref.g.9"><b>1 5.3</b></a></li>1921 <li class="indline1"><tt>extension-pragma</tt> <a class="iref" href="#rfc.iref.g.12"><b>1 5.4</b></a></li>1922 <li class="indline1"><tt>Pragma</tt> <a class="iref" href="#rfc.iref.g.10"><b>1 5.4</b></a></li>1923 <li class="indline1"><tt>pragma-directive</tt> <a class="iref" href="#rfc.iref.g.11"><b>1 5.4</b></a></li>1924 <li class="indline1"><tt>Vary</tt> <a class="iref" href="#rfc.iref.g.13"><b>1 5.5</b></a></li>1925 <li class="indline1"><tt>warn-agent</tt> <a class="iref" href="#rfc.iref.g.17"><b>1 5.6</b></a></li>1926 <li class="indline1"><tt>warn-code</tt> <a class="iref" href="#rfc.iref.g.16"><b>1 5.6</b></a></li>1927 <li class="indline1"><tt>warn-date</tt> <a class="iref" href="#rfc.iref.g.19"><b>1 5.6</b></a></li>1928 <li class="indline1"><tt>warn-text</tt> <a class="iref" href="#rfc.iref.g.18"><b>1 5.6</b></a></li>1929 <li class="indline1"><tt>Warning</tt> <a class="iref" href="#rfc.iref.g.14"><b>1 5.6</b></a></li>1930 <li class="indline1"><tt>warning-value</tt> <a class="iref" href="#rfc.iref.g.15"><b>1 5.6</b></a></li>1929 <li class="indline1"><tt>Age</tt> <a class="iref" href="#rfc.iref.g.1"><b>16.1</b></a></li> 1930 <li class="indline1"><tt>age-value</tt> <a class="iref" href="#rfc.iref.g.2"><b>16.1</b></a></li> 1931 <li class="indline1"><tt>Cache-Control</tt> <a class="iref" href="#rfc.iref.g.4"><b>16.2</b></a></li> 1932 <li class="indline1"><tt>cache-directive</tt> <a class="iref" href="#rfc.iref.g.5"><b>16.2</b></a></li> 1933 <li class="indline1"><tt>cache-extension</tt> <a class="iref" href="#rfc.iref.g.8"><b>16.2</b></a></li> 1934 <li class="indline1"><tt>cache-request-directive</tt> <a class="iref" href="#rfc.iref.g.6"><b>16.2</b></a></li> 1935 <li class="indline1"><tt>cache-response-directive</tt> <a class="iref" href="#rfc.iref.g.7"><b>16.2</b></a></li> 1936 <li class="indline1"><tt>delta-seconds</tt> <a class="iref" href="#rfc.iref.g.3"><b>16.1</b></a></li> 1937 <li class="indline1"><tt>Expires</tt> <a class="iref" href="#rfc.iref.g.9"><b>16.3</b></a></li> 1938 <li class="indline1"><tt>extension-pragma</tt> <a class="iref" href="#rfc.iref.g.12"><b>16.4</b></a></li> 1939 <li class="indline1"><tt>Pragma</tt> <a class="iref" href="#rfc.iref.g.10"><b>16.4</b></a></li> 1940 <li class="indline1"><tt>pragma-directive</tt> <a class="iref" href="#rfc.iref.g.11"><b>16.4</b></a></li> 1941 <li class="indline1"><tt>Vary</tt> <a class="iref" href="#rfc.iref.g.13"><b>16.5</b></a></li> 1942 <li class="indline1"><tt>warn-agent</tt> <a class="iref" href="#rfc.iref.g.17"><b>16.6</b></a></li> 1943 <li class="indline1"><tt>warn-code</tt> <a class="iref" href="#rfc.iref.g.16"><b>16.6</b></a></li> 1944 <li class="indline1"><tt>warn-date</tt> <a class="iref" href="#rfc.iref.g.19"><b>16.6</b></a></li> 1945 <li class="indline1"><tt>warn-text</tt> <a class="iref" href="#rfc.iref.g.18"><b>16.6</b></a></li> 1946 <li class="indline1"><tt>Warning</tt> <a class="iref" href="#rfc.iref.g.14"><b>16.6</b></a></li> 1947 <li class="indline1"><tt>warning-value</tt> <a class="iref" href="#rfc.iref.g.15"><b>16.6</b></a></li> 1931 1948 </ul> 1932 1949 </li> … … 1936 1953 <li class="indline1">Headers 1937 1954 <ul class="ind"> 1938 <li class="indline1">Age <a class="iref" href="#rfc.iref.h.2"><b>1 5.1</b></a></li>1939 <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>1940 <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>1941 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1">1 5.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>15.4</b></a></li>1942 <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>1943 <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>1955 <li class="indline1">Age <a class="iref" href="#rfc.iref.h.2"><b>16.1</b></a></li> 1956 <li class="indline1">Cache-Control <a class="iref" href="#rfc.xref.header.cache-control.1">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">3.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">3.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">4.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">4.5</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">6</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">6</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">10</a>, <a class="iref" href="#rfc.iref.h.3"><b>16.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.9">16.3</a>, <a class="iref" href="#rfc.xref.header.cache-control.10">16.4</a>, <a class="iref" href="#rfc.xref.header.cache-control.11">A.1</a></li> 1957 <li class="indline1">Expires <a class="iref" href="#rfc.xref.header.expires.1">6</a>, <a class="iref" href="#rfc.xref.header.expires.2">16.2.3</a>, <a class="iref" href="#rfc.iref.h.4"><b>16.3</b></a></li> 1958 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1">16.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>16.4</b></a></li> 1959 <li class="indline1">Vary <a class="iref" href="#rfc.xref.header.vary.1">8</a>, <a class="iref" href="#rfc.iref.h.6"><b>16.5</b></a></li> 1960 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">3.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">7.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">7.3</a>, <a class="iref" href="#rfc.iref.h.7"><b>16.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li> 1944 1961 </ul> 1945 1962 </li> … … 1948 1965 </li> 1949 1966 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 1950 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">1 5.6</a>, <a class="iref" href="#ISO-8859-1"><b>19.1</b></a></li>1967 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">16.6</a>, <a class="iref" href="#ISO-8859-1"><b>20.1</b></a></li> 1951 1968 </ul> 1952 1969 </li> … … 1954 1971 <li class="indline1">max-age 1955 1972 <ul class="ind"> 1956 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.1"><b>1 5.2.3</b></a>, <a class="iref" href="#rfc.iref.m.4"><b>15.2.4</b></a></li>1973 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.1"><b>16.2.3</b></a>, <a class="iref" href="#rfc.iref.m.4"><b>16.2.4</b></a></li> 1957 1974 </ul> 1958 1975 </li> 1959 1976 <li class="indline1">max-stale 1960 1977 <ul class="ind"> 1961 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.3"><b>1 5.2.3</b></a></li>1978 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.3"><b>16.2.3</b></a></li> 1962 1979 </ul> 1963 1980 </li> 1964 1981 <li class="indline1">min-fresh 1965 1982 <ul class="ind"> 1966 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.2"><b>1 5.2.3</b></a></li>1983 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.2"><b>16.2.3</b></a></li> 1967 1984 </ul> 1968 1985 </li> 1969 1986 <li class="indline1">must-revalidate 1970 1987 <ul class="ind"> 1971 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.5"><b>1 5.2.4</b></a></li>1988 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.m.5"><b>16.2.4</b></a></li> 1972 1989 </ul> 1973 1990 </li> … … 1977 1994 <li class="indline1">no-cache 1978 1995 <ul class="ind"> 1979 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.1"><b>1 5.2.1</b></a></li>1996 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.1"><b>16.2.1</b></a></li> 1980 1997 </ul> 1981 1998 </li> 1982 1999 <li class="indline1">no-store 1983 2000 <ul class="ind"> 1984 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.2"><b>1 5.2.2</b></a></li>2001 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.2"><b>16.2.2</b></a></li> 1985 2002 </ul> 1986 2003 </li> 1987 2004 <li class="indline1">no-transform 1988 2005 <ul class="ind"> 1989 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.3"><b>1 5.2.5</b></a></li>2006 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.n.3"><b>16.2.5</b></a></li> 1990 2007 </ul> 1991 2008 </li> … … 1995 2012 <li class="indline1">only-if-cached 1996 2013 <ul class="ind"> 1997 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.o.1"><b>1 5.2.4</b></a></li>2014 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.o.1"><b>16.2.4</b></a></li> 1998 2015 </ul> 1999 2016 </li> … … 2001 2018 </li> 2002 2019 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2003 <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"> 2004 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.6">15.3</a></li> 2005 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.5">7</a></li> 2006 <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> 2007 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part1.2">6.1</a></li> 2008 <li class="indline1"><em>Section 8.3</em> <a class="iref" href="#rfc.xref.Part1.1">3.3</a></li> 2020 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.13">4.3</a>, <a class="iref" href="#rfc.xref.Part1.14">7.1</a>, <a class="iref" href="#rfc.xref.Part1.15">7.2</a>, <a class="iref" href="#rfc.xref.Part1.16">7.2</a>, <a class="iref" href="#rfc.xref.Part1.17">8</a>, <a class="iref" href="#rfc.xref.Part1.18">16.3</a>, <a class="iref" href="#Part1"><b>20.1</b></a>, <a class="iref" href="#rfc.xref.Part1.19">A.1</a><ul class="ind"> 2021 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 2022 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 2023 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li> 2024 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.18">16.3</a></li> 2025 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.17">8</a></li> 2026 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.15">7.2</a>, <a class="iref" href="#rfc.xref.Part1.16">7.2</a></li> 2027 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part1.14">7.1</a></li> 2028 <li class="indline1"><em>Section 8.3</em> <a class="iref" href="#rfc.xref.Part1.13">4.3</a></li> 2029 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.11">2</a></li> 2009 2030 </ul> 2010 2031 </li> 2011 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1 0</a>, <a class="iref" href="#Part2"><b>19.1</b></a><ul class="ind">2012 <li class="indline1"><em>Section 7.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">10</a></li>2032 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">11</a>, <a class="iref" href="#Part2"><b>20.1</b></a><ul class="ind"> 2033 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">11</a></li> 2013 2034 </ul> 2014 2035 </li> 2015 <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">2016 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.Part3.1">6.2</a></li>2017 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.2">7</a></li>2036 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">7.2</a>, <a class="iref" href="#rfc.xref.Part3.2">8</a>, <a class="iref" href="#Part3"><b>20.1</b></a>, <a class="iref" href="#rfc.xref.Part3.3">A.1</a><ul class="ind"> 2037 <li class="indline1"><em>Section 4.2.2</em> <a class="iref" href="#rfc.xref.Part3.1">7.2</a></li> 2038 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part3.2">8</a></li> 2018 2039 </ul> 2019 2040 </li> 2020 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1"> 4</a>, <a class="iref" href="#Part4"><b>19.1</b></a></li>2021 <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">2022 <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>2041 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">5</a>, <a class="iref" href="#Part4"><b>20.1</b></a></li> 2042 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">7.3</a>, <a class="iref" href="#rfc.xref.Part5.2">10</a>, <a class="iref" href="#Part5"><b>20.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind"> 2043 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part5.1">7.3</a>, <a class="iref" href="#rfc.xref.Part5.2">10</a></li> 2023 2044 </ul> 2024 2045 </li> 2025 <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">2026 <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>2046 <li class="indline1"><em>Part7</em> <a class="iref" href="#rfc.xref.Part7.1">6</a>, <a class="iref" href="#rfc.xref.Part7.2">16.2.1</a>, <a class="iref" href="#Part7"><b>20.1</b></a><ul class="ind"> 2047 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part7.1">6</a>, <a class="iref" href="#rfc.xref.Part7.2">16.2.1</a></li> 2027 2048 </ul> 2028 2049 </li> 2029 <li class="indline1">Pragma header <a class="iref" href="#rfc.xref.header.pragma.1">1 5.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>15.4</b></a></li>2050 <li class="indline1">Pragma header <a class="iref" href="#rfc.xref.header.pragma.1">16.2</a>, <a class="iref" href="#rfc.iref.p.4"><b>16.4</b></a></li> 2030 2051 <li class="indline1">private 2031 2052 <ul class="ind"> 2032 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.2"><b>1 5.2.1</b></a></li>2053 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.2"><b>16.2.1</b></a></li> 2033 2054 </ul> 2034 2055 </li> 2035 2056 <li class="indline1">proxy-revalidate 2036 2057 <ul class="ind"> 2037 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.3"><b>1 5.2.4</b></a></li>2058 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.3"><b>16.2.4</b></a></li> 2038 2059 </ul> 2039 2060 </li> 2040 2061 <li class="indline1">public 2041 2062 <ul class="ind"> 2042 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.1"><b>1 5.2.1</b></a></li>2063 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.p.1"><b>16.2.1</b></a></li> 2043 2064 </ul> 2044 2065 </li> … … 2046 2067 </li> 2047 2068 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 2048 <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>2049 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">1 5.6</a>, <a class="iref" href="#RFC2047"><b>19.1</b></a></li>2050 <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>2051 <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>2069 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">4.3</a>, <a class="iref" href="#RFC1305"><b>20.2</b></a></li> 2070 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">16.6</a>, <a class="iref" href="#RFC2047"><b>20.1</b></a></li> 2071 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.3</a>, <a class="iref" href="#RFC2119"><b>20.1</b></a></li> 2072 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#RFC2616"><b>20.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li> 2052 2073 </ul> 2053 2074 </li> … … 2055 2076 <li class="indline1">s-maxage 2056 2077 <ul class="ind"> 2057 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.s.3"><b>1 5.2.3</b></a></li>2078 <li class="indline1">Cache Directive <a class="iref" href="#rfc.iref.s.3"><b>16.2.3</b></a></li> 2058 2079 </ul> 2059 2080 </li> … … 2064 2085 <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind"> 2065 2086 <li class="indline1">validator <a class="iref" href="#rfc.iref.v.1">1.2</a></li> 2066 <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>2087 <li class="indline1">Vary header <a class="iref" href="#rfc.xref.header.vary.1">8</a>, <a class="iref" href="#rfc.iref.v.2"><b>16.5</b></a></li> 2067 2088 </ul> 2068 2089 </li> 2069 2090 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 2070 <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>2091 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">3.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">7.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">7.3</a>, <a class="iref" href="#rfc.iref.w.1"><b>16.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li> 2071 2092 </ul> 2072 2093 </li>
Note: See TracChangeset
for help on using the changeset viewer.