Changeset 2372
- Timestamp:
- 07/09/13 23:32:58 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2369 r2372 446 446 } 447 447 @bottom-center { 448 content: "Expires March 8, 2014";448 content: "Expires March 11, 2014"; 449 449 } 450 450 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-09-0 4">493 <meta name="dct.issued" scheme="ISO8601" content="2013-09-07"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 519 519 <tr> 520 520 <td class="left">Intended status: Standards Track</td> 521 <td class="right">September 4, 2013</td>521 <td class="right">September 7, 2013</td> 522 522 </tr> 523 523 <tr> 524 <td class="left">Expires: March 8, 2014</td>524 <td class="left">Expires: March 11, 2014</td> 525 525 <td class="right"></td> 526 526 </tr> … … 550 550 in progress”. 551 551 </p> 552 <p>This Internet-Draft will expire on March 8, 2014.</p>552 <p>This Internet-Draft will expire on March 11, 2014.</p> 553 553 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 554 554 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1416 1416 existing implementations to reject the request. 1417 1417 </p> 1418 <p id="rfc.section.4.3.1.p.5">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).1418 <p id="rfc.section.4.3.1.p.5">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1419 1419 </p> 1420 1420 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> … … 1427 1427 existing implementations to reject the request. 1428 1428 </p> 1429 <p id="rfc.section.4.3.2.p.3">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.1429 <p id="rfc.section.4.3.2.p.3">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached responses to GET; see <a href="p6-cache.html#head.effects" title="Freshening Responses via HEAD">Section 4.3.5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 1430 1430 </p> 1431 1431 <div id="rfc.iref.p.2"></div> … … 1447 1447 origin server <em class="bcp14">SHOULD</em> send a <a href="#status.201" class="smpl">201 (Created)</a> response containing a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (<a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>) and a representation that describes the status of the request while referring to the new resource(s). 1448 1448 </p> 1449 <p id="rfc.section.4.3.3.p.4">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4. 1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache1449 <p id="rfc.section.4.3.3.p.4">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache 1450 1450 the result of a POST in a way that can be reused by a later GET, the origin server <em class="bcp14">MAY</em> send a <a href="#status.200" class="smpl">200 (OK)</a> response containing the result and a <a href="#header.content-location" class="smpl">Content-Location</a> header field that has the same value as the POST's effective request URI (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 3.1.4.2</a>). 1451 1451 </p> … … 1521 1521 </p> 1522 1522 <p id="rfc.section.4.3.4.p.12">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses 1523 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation .after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).1523 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation" title="Invalidation">Section 4.4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1524 1524 </p> 1525 1525 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> … … 1547 1547 </p> 1548 1548 <p id="rfc.section.4.3.5.p.6">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1549 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation .after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).1549 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation" title="Invalidation">Section 4.4</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1550 1550 </p> 1551 1551 <div id="rfc.iref.c.9"></div> … … 1646 1646 <tr> 1647 1647 <td class="left">Cache-Control</td> 1648 <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>1648 <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 1649 1649 </tr> 1650 1650 <tr> … … 1662 1662 <tr> 1663 1663 <td class="left">Pragma</td> 1664 <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 7.4</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>1664 <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 5.4</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 1665 1665 </tr> 1666 1666 <tr> … … 2478 2478 200 response header block. 2479 2479 </p> 2480 <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2480 <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2481 2481 </p> 2482 2482 <div id="rfc.iref.74"></div> … … 2505 2505 applicable along the same request path (through the same proxies). 2506 2506 </p> 2507 <p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), which has the advantage of being applicable to responses with any status code.2508 </p> 2509 <p id="rfc.section.6.3.4.p.3">A 203 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2507 <p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), which has the advantage of being applicable to responses with any status code. 2508 </p> 2509 <p id="rfc.section.6.3.4.p.3">A 203 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2510 2510 </p> 2511 2511 <div id="rfc.iref.74"></div> … … 2527 2527 </p> 2528 2528 <p id="rfc.section.6.3.5.p.5">A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.</p> 2529 <p id="rfc.section.6.3.5.p.6">A 204 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2529 <p id="rfc.section.6.3.5.p.6">A 204 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2530 2530 </p> 2531 2531 <div id="rfc.iref.74"></div> … … 2592 2592 for such automatic selection. 2593 2593 </p> 2594 <p id="rfc.section.6.4.1.p.4">A 300 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2594 <p id="rfc.section.6.4.1.p.4">A 300 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2595 2595 </p> 2596 2596 <div class="note" id="rfc.section.6.4.1.p.5"> … … 2614 2614 </p> 2615 2615 </div> 2616 <p id="rfc.section.6.4.2.p.4">A 301 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2616 <p id="rfc.section.6.4.2.p.4">A 301 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2617 2617 </p> 2618 2618 <div id="rfc.iref.75"></div> … … 2698 2698 is likely to be permanent. 2699 2699 </p> 2700 <p id="rfc.section.6.5.4.p.2">A 404 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2700 <p id="rfc.section.6.5.4.p.2">A 404 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2701 2701 </p> 2702 2702 <div id="rfc.iref.76"></div> … … 2704 2704 <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods. 2705 2705 </p> 2706 <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2706 <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2707 2707 </p> 2708 2708 <div id="rfc.iref.76"></div> … … 2741 2741 any length of time — that is left to the discretion of the server owner. 2742 2742 </p> 2743 <p id="rfc.section.6.5.9.p.3">A 410 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2743 <p id="rfc.section.6.5.9.p.3">A 410 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2744 2744 </p> 2745 2745 <div id="rfc.iref.76"></div> … … 2762 2762 attempting to exploit potential security holes. 2763 2763 </p> 2764 <p id="rfc.section.6.5.12.p.2">A 414 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2764 <p id="rfc.section.6.5.12.p.2">A 414 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2765 2765 </p> 2766 2766 <div id="rfc.iref.76"></div> … … 2802 2802 response when the server does not recognize the request method and is not capable of supporting it for any resource. 2803 2803 </p> 2804 <p id="rfc.section.6.6.2.p.2">A 501 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2804 <p id="rfc.section.6.6.2.p.2">A 501 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2805 2805 </p> 2806 2806 <div id="rfc.iref.77"></div> … … 2853 2853 <tr> 2854 2854 <td class="left">Age</td> 2855 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>2855 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 5.1</a> of <a href="#Part6" id="rfc.xref.Part6.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2856 2856 </tr> 2857 2857 <tr> 2858 2858 <td class="left">Cache-Control</td> 2859 <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>2859 <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2860 2860 </tr> 2861 2861 <tr> 2862 2862 <td class="left">Expires</td> 2863 <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>2863 <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 5.3</a> of <a href="#Part6" id="rfc.xref.Part6.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2864 2864 </tr> 2865 2865 <tr> … … 2881 2881 <tr> 2882 2882 <td class="left">Warning</td> 2883 <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>2883 <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2884 2884 </tr> 2885 2885 </tbody> … … 3076 3076 <li> 3077 3077 <p>To inform cache recipients that they <em class="bcp14">MUST NOT</em> use this response to satisfy a later request unless the later request has the same values for the listed fields as the original 3078 request (<a href="p6-cache.html#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a> of <a href="#Part6" id="rfc.xref.Part6.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry.3078 request (<a href="p6-cache.html#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a> of <a href="#Part6" id="rfc.xref.Part6.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry. 3079 3079 </p> 3080 3080 </li> … … 3088 3088 other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately 3089 3089 configured to prevent cache transparency. For example, there is no need to send the Authorization field name in Vary because 3090 reuse across users is constrained by the field definition (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>). Likewise, an origin server might use Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.3090 reuse across users is constrained by the field definition (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>). Likewise, an origin server might use Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching. 3091 3091 </p> 3092 3092 <div id="rfc.iref.s.8"></div> … … 4793 4793 </li> 4794 4794 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">4.2.3</a>, <a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.9">5.1</a>, <a href="#rfc.xref.Part6.10">6.1</a>, <a href="#rfc.xref.Part6.11">6.3.1</a>, <a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.3.5</a>, <a href="#rfc.xref.Part6.15">6.4.1</a>, <a href="#rfc.xref.Part6.16">6.4.2</a>, <a href="#rfc.xref.Part6.17">6.5.4</a>, <a href="#rfc.xref.Part6.18">6.5.5</a>, <a href="#rfc.xref.Part6.19">6.5.9</a>, <a href="#rfc.xref.Part6.20">6.5.12</a>, <a href="#rfc.xref.Part6.21">6.6.2</a>, <a href="#rfc.xref.Part6.22">7.1</a>, <a href="#rfc.xref.Part6.23">7.1</a>, <a href="#rfc.xref.Part6.24">7.1</a>, <a href="#rfc.xref.Part6.25">7.1</a>, <a href="#rfc.xref.Part6.26">7.1.4</a>, <a href="#rfc.xref.Part6.27">7.1.4</a>, <a href="#rfc.xref.Part6.28">8.2.2</a>, <a href="#Part6"><b>11.1</b></a><ul> 4795 <li><em>Section 4.1 .1</em> <a href="#rfc.xref.Part6.5">4.3.3</a></li>4796 <li><em>Section 4. 1.2</em> <a href="#rfc.xref.Part6.11">6.3.1</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.3.5</a>, <a href="#rfc.xref.Part6.15">6.4.1</a>, <a href="#rfc.xref.Part6.16">6.4.2</a>, <a href="#rfc.xref.Part6.17">6.5.4</a>, <a href="#rfc.xref.Part6.18">6.5.5</a>, <a href="#rfc.xref.Part6.19">6.5.9</a>, <a href="#rfc.xref.Part6.20">6.5.12</a>, <a href="#rfc.xref.Part6.21">6.6.2</a></li>4797 <li><em>Section 4. 3</em> <a href="#rfc.xref.Part6.26">7.1.4</a></li>4798 <li><em>Section 5</em> <a href="#rfc.xref.Part6.4">4.3.2</a></li>4799 <li><em>Section 6</em> <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li>4800 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.22">7.1</a></li>4801 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.23">7.1</a>, <a href="#rfc.xref.Part6.27">7.1.4</a></li>4802 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.24">7.1</a></li>4803 <li><em>Section 7.4</em> <a href="#rfc.xref.Part6.9">5.1</a></li>4804 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.25">7.1</a></li>4795 <li><em>Section 4.1</em> <a href="#rfc.xref.Part6.26">7.1.4</a></li> 4796 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part6.5">4.3.3</a></li> 4797 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part6.11">6.3.1</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.3.5</a>, <a href="#rfc.xref.Part6.15">6.4.1</a>, <a href="#rfc.xref.Part6.16">6.4.2</a>, <a href="#rfc.xref.Part6.17">6.5.4</a>, <a href="#rfc.xref.Part6.18">6.5.5</a>, <a href="#rfc.xref.Part6.19">6.5.9</a>, <a href="#rfc.xref.Part6.20">6.5.12</a>, <a href="#rfc.xref.Part6.21">6.6.2</a></li> 4798 <li><em>Section 4.3.5</em> <a href="#rfc.xref.Part6.4">4.3.2</a></li> 4799 <li><em>Section 4.4</em> <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li> 4800 <li><em>Section 5.1</em> <a href="#rfc.xref.Part6.22">7.1</a></li> 4801 <li><em>Section 5.2</em> <a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.23">7.1</a>, <a href="#rfc.xref.Part6.27">7.1.4</a></li> 4802 <li><em>Section 5.3</em> <a href="#rfc.xref.Part6.24">7.1</a></li> 4803 <li><em>Section 5.4</em> <a href="#rfc.xref.Part6.9">5.1</a></li> 4804 <li><em>Section 5.5</em> <a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.25">7.1</a></li> 4805 4805 </ul> 4806 4806 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2369 r2372 89 89 <!ENTITY p6-heuristic "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 90 90 <!ENTITY p6-explicit "<xref target='Part6' x:rel='#calculating.freshness.lifetime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 91 <!ENTITY p6-invalid "<xref target='Part6' x:rel='#invalidation .after.updates.or.deletions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">91 <!ENTITY p6-invalid "<xref target='Part6' x:rel='#invalidation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 92 92 <!ENTITY p6-head "<xref target='Part6' x:rel='#head.effects' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 93 93 <!ENTITY qvalue "<xref target='quality.values'/>"> -
draft-ietf-httpbis/latest/p4-conditional.html
r2369 r2372 446 446 } 447 447 @bottom-center { 448 content: "Expires March 8, 2014";448 content: "Expires March 11, 2014"; 449 449 } 450 450 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-0 4">491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-07"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 515 515 </tr> 516 516 <tr> 517 <td class="left">Expires: March 8, 2014</td>518 <td class="right">September 4, 2013</td>517 <td class="left">Expires: March 11, 2014</td> 518 <td class="right">September 7, 2013</td> 519 519 </tr> 520 520 </tbody> … … 543 543 in progress”. 544 544 </p> 545 <p>This Internet-Draft will expire on March 8, 2014.</p>545 <p>This Internet-Draft will expire on March 11, 2014.</p> 546 546 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 547 547 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 933 933 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. <a href="#evaluation" title="Evaluation">Section 5</a> defines when the preconditions are applied. <a href="#precedence" title="Precedence">Section 6</a> defines the order of evaluation when more than one precondition is present. 934 934 </p> 935 <p id="rfc.section.3.p.2">Requirements on a cache when handling a received conditional request are defined in <a href="p6-cache.html#validation.received" title="Handling a Received Validation Request">Section 4.3.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 936 </p> 935 937 <div id="rfc.iref.i.1"></div> 936 938 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2> … … 957 959 user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior 958 960 change made by the same user agent. 959 </p>960 <p id="rfc.section.3.1.p.8">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">MUST</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">MUST</em> generate a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response if the field-value is "*" and no suitable response is stored, or if the field-value is a list of entity-tags and961 none of them match the entity-tag of a suitable stored response. Otherwise, the cache <em class="bcp14">MUST</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most recent of its matching stored responses to satisfy the request.962 961 </p> 963 962 <div id="rfc.iref.i.2"></div> … … 989 988 <p id="rfc.section.3.2.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD; or, b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods. 990 989 </p> 991 <p id="rfc.section.3.2.p.9">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">SHOULD</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the field-value is "*" and a suitable response is stored, or the field-value is a list of entity-tags and at least one992 of them match the entity-tag of a suitable stored response, the cache <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response using the most suitable of those matching responses as the selected representation. Otherwise, if the cache has one993 or more suitable stored responses that do not match the condition, the cache <em class="bcp14">SHOULD</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most suitable of those stored responses to satisfy the request. Finally, if the cache has no suitable994 stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server; if the received condition contains a list of entity-tags and the995 cache has its own set of stored responses for that primary cache key, the cache <em class="bcp14">SHOULD</em> take the union of the received set with the set of entity-tags for its own stored set of responses (fresh or stale) and generate996 an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field containing that union when it forwards the request toward the origin server.997 </p>998 990 <div id="rfc.iref.i.3"></div> 999 991 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2> … … 1028 1020 selected representation's <a href="#header.last-modified" class="smpl">Last-Modified</a> field will not be able to help the user agent limit its data transfers to only those changed during the specified window. 1029 1021 </p> 1030 <p id="rfc.section.3.3.p.11">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">SHOULD</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server if it does not have any suitable stored responses. The cache <em class="bcp14">SHOULD</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response, reusing the most recent of its stored responses to satisfy the request, if one of the following is true: 1) a stored1031 response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp.1032 Otherwise, the cache <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response using the most recent of the stored responses as the selected representation.1033 </p>1034 1022 <div id="rfc.iref.i.4"></div> 1035 1023 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2> … … 1058 1046 user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior 1059 1047 change made by the same user agent. 1060 </p>1061 <p id="rfc.section.3.4.p.11">If the request semantics can be satisfied with a cached response, a recipient cache <em class="bcp14">MUST</em> evaluate the condition as part of its selection process for determining a suitable response for that primary cache key (see <a href="p6-cache.html#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). The cache <em class="bcp14">MUST</em> forward the conditional request toward the origin server if it does not have any suitable stored responses. The cache <em class="bcp14">MUST</em> generate a successful <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> response that reuses the most recent of its suitable stored responses to satisfy the request if that stored response has a <a href="#header.last-modified" class="smpl">Last-Modified</a> date that is equal to or earlier than the date given in If-Unmodified-Since. Otherwise, the cache <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.1062 1048 </p> 1063 1049 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> … … 1079 1065 cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field). 1080 1066 </p> 1081 <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4. 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional1067 <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3.4</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional 1082 1068 GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client. 1083 1069 </p> … … 1529 1515 </ul> 1530 1516 </li> 1531 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3 .1</a>, <a href="#rfc.xref.Part6.5">3.2</a>, <a href="#rfc.xref.Part6.6">3.3</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">4.1</a>, <a href="#Part6"><b>10.1</b></a><ul>1532 <li><em>Section 4 </em> <a href="#rfc.xref.Part6.4">3.1</a>, <a href="#rfc.xref.Part6.5">3.2</a>, <a href="#rfc.xref.Part6.6">3.3</a>, <a href="#rfc.xref.Part6.7">3.4</a></li>1533 <li><em>Section 4. 2.1</em> <a href="#rfc.xref.Part6.8">4.1</a></li>1517 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#rfc.xref.Part6.4">3</a>, <a href="#rfc.xref.Part6.5">4.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 1518 <li><em>Section 4.3.2</em> <a href="#rfc.xref.Part6.4">3</a></li> 1519 <li><em>Section 4.3.4</em> <a href="#rfc.xref.Part6.5">4.1</a></li> 1534 1520 </ul> 1535 1521 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2369 r2372 30 30 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 31 <!ENTITY cache-key "<xref target='Part6' x:rel='#constructing.responses.from.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 <!ENTITY cache-validation-received "<xref target='Part6' x:rel='#validation.received' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 33 <!ENTITY freshening-responses "<xref target='Part6' x:rel='#freshening.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 34 <!ENTITY header-accept-encoding "<xref target='Part2' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 658 659 one precondition is present. 659 660 </t> 661 <t> 662 Requirements on a cache when handling a received conditional request are 663 defined in &cache-validation-received;. 664 </t> 660 665 661 666 <section title="If-Match" anchor="header.if-match"> … … 714 719 of an immediately prior change made by the same user agent. 715 720 </t> 716 <t>717 If the request semantics can be satisfied with a cached response, a718 recipient cache &MUST; evaluate the condition as part of its selection719 process for determining a suitable response for that primary cache key720 (see &cache-key;).721 The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref>722 response if the field-value is "*" and no suitable response is stored, or723 if the field-value is a list of entity-tags and none of them match the724 entity-tag of a suitable stored response.725 Otherwise, the cache &MUST; generate a successful <x:ref>2xx</x:ref>726 response that reuses the most recent of its matching stored responses to727 satisfy the request.728 </t>729 721 </section> 730 722 … … 789 781 b) the <x:ref>412 (Precondition Failed)</x:ref> status code for all other 790 782 request methods. 791 </t>792 <t>793 If the request semantics can be satisfied with a cached response, a794 recipient cache &SHOULD; evaluate the condition as part of its selection795 process for determining a suitable response for that primary cache key796 (see &cache-key;). If the field-value is "*" and a suitable response is797 stored, or the field-value is a list of entity-tags and at least one of798 them match the entity-tag of a suitable stored response, the cache &SHOULD;799 generate a <x:ref>304 (Not Modified)</x:ref> response using the most800 suitable of those matching responses as the selected representation.801 Otherwise, if the cache has one or more suitable stored responses that802 do not match the condition, the cache &SHOULD; generate a successful803 <x:ref>2xx</x:ref> response that reuses the most suitable of those stored804 responses to satisfy the request. Finally, if the cache has no suitable805 stored responses, the cache &SHOULD; forward the conditional request toward806 the origin server; if the received condition contains a list of entity-tags807 and the cache has its own set of stored responses for that primary cache808 key, the cache &SHOULD; take the union of the received set with the set of809 entity-tags for its own stored set of responses (fresh or stale) and810 generate an <x:ref>If-None-Match</x:ref> header field containing that union811 when it forwards the request toward the origin server.812 783 </t> 813 784 </section> … … 883 854 field will not be able to help the user agent limit its data transfers to 884 855 only those changed during the specified window. 885 </t>886 <t>887 If the request semantics can be satisfied with a cached response, a888 recipient cache &SHOULD; evaluate the condition as part of its selection889 process for determining a suitable response for that primary cache key890 (see &cache-key;).891 The cache &SHOULD; forward the conditional request toward the origin server892 if it does not have any suitable stored responses.893 The cache &SHOULD; generate a successful894 <x:ref>2xx</x:ref> response, reusing the most recent of its stored895 responses to satisfy the request, if one of the following is true:896 1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that897 is more recent than the conditional timestamp;898 2) no <x:ref>Last-Modified</x:ref> field is present, but a stored899 response has a <x:ref>Date</x:ref> field-value that is more recent than the900 conditional timestamp; or,901 3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present,902 but the cache recorded a stored response as having been received at a903 time more recent than the conditional timestamp.904 Otherwise, the cache &SHOULD; generate a <x:ref>304 (Not Modified)</x:ref>905 response using the most recent of the stored responses as the selected906 representation.907 856 </t> 908 857 </section> … … 973 922 of an immediately prior change made by the same user agent. 974 923 </t> 975 <t>976 If the request semantics can be satisfied with a cached response, a977 recipient cache &MUST; evaluate the condition as part of its selection978 process for determining a suitable response for that primary cache key979 (see &cache-key;).980 The cache &MUST; forward the conditional request toward the origin server981 if it does not have any suitable stored responses.982 The cache &MUST; generate a successful <x:ref>2xx</x:ref> response that983 reuses the most recent of its suitable stored responses to satisfy the984 request if that stored response has a <x:ref>Last-Modified</x:ref> date985 that is equal to or earlier than the date given in If-Unmodified-Since.986 Otherwise, the cache &MUST; respond with a987 <x:ref>412 (Precondition Failed)</x:ref> status code.988 </t>989 924 </section> 990 925 … … 999 934 </t> 1000 935 </section> 1001 1002 936 </section> 1003 937 -
draft-ietf-httpbis/latest/p6-cache.html
r2371 r2372 475 475 <link rel="Chapter" title="3 Storing Responses in Caches" href="#rfc.section.3"> 476 476 <link rel="Chapter" title="4 Constructing Responses from Caches" href="#rfc.section.4"> 477 <link rel="Chapter" title="5 Updating Caches with HEAD Responses" href="#rfc.section.5"> 478 <link rel="Chapter" title="6 Request Methods that Invalidate" href="#rfc.section.6"> 479 <link rel="Chapter" title="7 Header Field Definitions" href="#rfc.section.7"> 480 <link rel="Chapter" title="8 History Lists" href="#rfc.section.8"> 481 <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9"> 482 <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10"> 483 <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11"> 484 <link rel="Chapter" href="#rfc.section.12" title="12 References"> 477 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> 478 <link rel="Chapter" title="6 History Lists" href="#rfc.section.6"> 479 <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"> 480 <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"> 481 <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"> 482 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 485 483 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 486 484 <link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"> … … 599 597 </li> 600 598 <li><a href="#rfc.section.4.3">4.3</a> <a href="#validation.model">Validation</a><ul> 601 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li> 599 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="#validation.sent">Sending a Validation Request</a></li> 600 <li><a href="#rfc.section.4.3.2">4.3.2</a> <a href="#validation.received">Handling a Received Validation Request</a></li> 601 <li><a href="#rfc.section.4.3.3">4.3.3</a> <a href="#validation.response">Handling a Validation Response</a></li> 602 <li><a href="#rfc.section.4.3.4">4.3.4</a> <a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li> 603 <li><a href="#rfc.section.4.3.5">4.3.5</a> <a href="#head.effects">Freshening Responses via HEAD</a></li> 604 </ul> 605 </li> 606 <li><a href="#rfc.section.4.4">4.4</a> <a href="#invalidation">Invalidation</a></li> 607 </ul> 608 </li> 609 <li><a href="#rfc.section.5">5.</a> <a href="#header.field.definitions">Header Field Definitions</a><ul> 610 <li><a href="#rfc.section.5.1">5.1</a> <a href="#header.age">Age</a></li> 611 <li><a href="#rfc.section.5.2">5.2</a> <a href="#header.cache-control">Cache-Control</a><ul> 612 <li><a href="#rfc.section.5.2.1">5.2.1</a> <a href="#cache-request-directive">Request Cache-Control Directives</a><ul> 613 <li><a href="#rfc.section.5.2.1.1">5.2.1.1</a> <a href="#cache-request-directive.max-age">max-age</a></li> 614 <li><a href="#rfc.section.5.2.1.2">5.2.1.2</a> <a href="#cache-request-directive.max-stale">max-stale</a></li> 615 <li><a href="#rfc.section.5.2.1.3">5.2.1.3</a> <a href="#cache-request-directive.min-fresh">min-fresh</a></li> 616 <li><a href="#rfc.section.5.2.1.4">5.2.1.4</a> <a href="#cache-request-directive.no-cache">no-cache</a></li> 617 <li><a href="#rfc.section.5.2.1.5">5.2.1.5</a> <a href="#cache-request-directive.no-store">no-store</a></li> 618 <li><a href="#rfc.section.5.2.1.6">5.2.1.6</a> <a href="#cache-request-directive.no-transform">no-transform</a></li> 619 <li><a href="#rfc.section.5.2.1.7">5.2.1.7</a> <a href="#cache-request-directive.only-if-cached">only-if-cached</a></li> 620 </ul> 621 </li> 622 <li><a href="#rfc.section.5.2.2">5.2.2</a> <a href="#cache-response-directive">Response Cache-Control Directives</a><ul> 623 <li><a href="#rfc.section.5.2.2.1">5.2.2.1</a> <a href="#cache-response-directive.must-revalidate">must-revalidate</a></li> 624 <li><a href="#rfc.section.5.2.2.2">5.2.2.2</a> <a href="#cache-response-directive.no-cache">no-cache</a></li> 625 <li><a href="#rfc.section.5.2.2.3">5.2.2.3</a> <a href="#cache-response-directive.no-store">no-store</a></li> 626 <li><a href="#rfc.section.5.2.2.4">5.2.2.4</a> <a href="#cache-response-directive.no-transform">no-transform</a></li> 627 <li><a href="#rfc.section.5.2.2.5">5.2.2.5</a> <a href="#cache-response-directive.public">public</a></li> 628 <li><a href="#rfc.section.5.2.2.6">5.2.2.6</a> <a href="#cache-response-directive.private">private</a></li> 629 <li><a href="#rfc.section.5.2.2.7">5.2.2.7</a> <a href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></li> 630 <li><a href="#rfc.section.5.2.2.8">5.2.2.8</a> <a href="#cache-response-directive.max-age">max-age</a></li> 631 <li><a href="#rfc.section.5.2.2.9">5.2.2.9</a> <a href="#cache-response-directive.s-maxage">s-maxage</a></li> 632 </ul> 633 </li> 634 <li><a href="#rfc.section.5.2.3">5.2.3</a> <a href="#cache.control.extensions">Cache Control Extensions</a></li> 635 </ul> 636 </li> 637 <li><a href="#rfc.section.5.3">5.3</a> <a href="#header.expires">Expires</a></li> 638 <li><a href="#rfc.section.5.4">5.4</a> <a href="#header.pragma">Pragma</a></li> 639 <li><a href="#rfc.section.5.5">5.5</a> <a href="#header.warning">Warning</a><ul> 640 <li><a href="#rfc.section.5.5.1">5.5.1</a> <a href="#warn.110">110 Response is Stale</a></li> 641 <li><a href="#rfc.section.5.5.2">5.5.2</a> <a href="#warn.111">111 Revalidation Failed</a></li> 642 <li><a href="#rfc.section.5.5.3">5.5.3</a> <a href="#warn.112">112 Disconnected Operation</a></li> 643 <li><a href="#rfc.section.5.5.4">5.5.4</a> <a href="#warn.113">113 Heuristic Expiration</a></li> 644 <li><a href="#rfc.section.5.5.5">5.5.5</a> <a href="#warn.199">199 Miscellaneous Warning</a></li> 645 <li><a href="#rfc.section.5.5.6">5.5.6</a> <a href="#warn.214">214 Transformation Applied</a></li> 646 <li><a href="#rfc.section.5.5.7">5.5.7</a> <a href="#warn.299">299 Miscellaneous Persistent Warning</a></li> 647 <li><a href="#rfc.section.5.5.8">5.5.8</a> <a href="#warn.code.extensions">Warn Code Extensions</a></li> 602 648 </ul> 603 649 </li> 604 650 </ul> 605 651 </li> 606 <li><a href="#rfc.section.5">5.</a> <a href="#head.effects">Updating Caches with HEAD Responses</a></li> 607 <li><a href="#rfc.section.6">6.</a> <a href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></li> 608 <li><a href="#rfc.section.7">7.</a> <a href="#header.field.definitions">Header Field Definitions</a><ul> 609 <li><a href="#rfc.section.7.1">7.1</a> <a href="#header.age">Age</a></li> 610 <li><a href="#rfc.section.7.2">7.2</a> <a href="#header.cache-control">Cache-Control</a><ul> 611 <li><a href="#rfc.section.7.2.1">7.2.1</a> <a href="#cache-request-directive">Request Cache-Control Directives</a><ul> 612 <li><a href="#rfc.section.7.2.1.1">7.2.1.1</a> <a href="#cache-request-directive.max-age">max-age</a></li> 613 <li><a href="#rfc.section.7.2.1.2">7.2.1.2</a> <a href="#cache-request-directive.max-stale">max-stale</a></li> 614 <li><a href="#rfc.section.7.2.1.3">7.2.1.3</a> <a href="#cache-request-directive.min-fresh">min-fresh</a></li> 615 <li><a href="#rfc.section.7.2.1.4">7.2.1.4</a> <a href="#cache-request-directive.no-cache">no-cache</a></li> 616 <li><a href="#rfc.section.7.2.1.5">7.2.1.5</a> <a href="#cache-request-directive.no-store">no-store</a></li> 617 <li><a href="#rfc.section.7.2.1.6">7.2.1.6</a> <a href="#cache-request-directive.no-transform">no-transform</a></li> 618 <li><a href="#rfc.section.7.2.1.7">7.2.1.7</a> <a href="#cache-request-directive.only-if-cached">only-if-cached</a></li> 619 </ul> 620 </li> 621 <li><a href="#rfc.section.7.2.2">7.2.2</a> <a href="#cache-response-directive">Response Cache-Control Directives</a><ul> 622 <li><a href="#rfc.section.7.2.2.1">7.2.2.1</a> <a href="#cache-response-directive.must-revalidate">must-revalidate</a></li> 623 <li><a href="#rfc.section.7.2.2.2">7.2.2.2</a> <a href="#cache-response-directive.no-cache">no-cache</a></li> 624 <li><a href="#rfc.section.7.2.2.3">7.2.2.3</a> <a href="#cache-response-directive.no-store">no-store</a></li> 625 <li><a href="#rfc.section.7.2.2.4">7.2.2.4</a> <a href="#cache-response-directive.no-transform">no-transform</a></li> 626 <li><a href="#rfc.section.7.2.2.5">7.2.2.5</a> <a href="#cache-response-directive.public">public</a></li> 627 <li><a href="#rfc.section.7.2.2.6">7.2.2.6</a> <a href="#cache-response-directive.private">private</a></li> 628 <li><a href="#rfc.section.7.2.2.7">7.2.2.7</a> <a href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></li> 629 <li><a href="#rfc.section.7.2.2.8">7.2.2.8</a> <a href="#cache-response-directive.max-age">max-age</a></li> 630 <li><a href="#rfc.section.7.2.2.9">7.2.2.9</a> <a href="#cache-response-directive.s-maxage">s-maxage</a></li> 631 </ul> 632 </li> 633 <li><a href="#rfc.section.7.2.3">7.2.3</a> <a href="#cache.control.extensions">Cache Control Extensions</a></li> 652 <li><a href="#rfc.section.6">6.</a> <a href="#history.lists">History Lists</a></li> 653 <li><a href="#rfc.section.7">7.</a> <a href="#iana.considerations">IANA Considerations</a><ul> 654 <li><a href="#rfc.section.7.1">7.1</a> <a href="#cache.directive.registry">Cache Directive Registry</a><ul> 655 <li><a href="#rfc.section.7.1.1">7.1.1</a> <a href="#cache.directive.registry.procedure">Procedure</a></li> 656 <li><a href="#rfc.section.7.1.2">7.1.2</a> <a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li> 657 <li><a href="#rfc.section.7.1.3">7.1.3</a> <a href="#cache.directive.registration">Registrations</a></li> 634 658 </ul> 635 659 </li> 636 <li><a href="#rfc.section.7.3">7.3</a> <a href="#header.expires">Expires</a></li> 637 <li><a href="#rfc.section.7.4">7.4</a> <a href="#header.pragma">Pragma</a></li> 638 <li><a href="#rfc.section.7.5">7.5</a> <a href="#header.warning">Warning</a><ul> 639 <li><a href="#rfc.section.7.5.1">7.5.1</a> <a href="#warn.110">110 Response is Stale</a></li> 640 <li><a href="#rfc.section.7.5.2">7.5.2</a> <a href="#warn.111">111 Revalidation Failed</a></li> 641 <li><a href="#rfc.section.7.5.3">7.5.3</a> <a href="#warn.112">112 Disconnected Operation</a></li> 642 <li><a href="#rfc.section.7.5.4">7.5.4</a> <a href="#warn.113">113 Heuristic Expiration</a></li> 643 <li><a href="#rfc.section.7.5.5">7.5.5</a> <a href="#warn.199">199 Miscellaneous Warning</a></li> 644 <li><a href="#rfc.section.7.5.6">7.5.6</a> <a href="#warn.214">214 Transformation Applied</a></li> 645 <li><a href="#rfc.section.7.5.7">7.5.7</a> <a href="#warn.299">299 Miscellaneous Persistent Warning</a></li> 646 <li><a href="#rfc.section.7.5.8">7.5.8</a> <a href="#warn.code.extensions">Warn Code Extensions</a></li> 660 <li><a href="#rfc.section.7.2">7.2</a> <a href="#warn.code.registry">Warn Code Registry</a><ul> 661 <li><a href="#rfc.section.7.2.1">7.2.1</a> <a href="#warn.code.registry.procedure">Procedure</a></li> 662 <li><a href="#rfc.section.7.2.2">7.2.2</a> <a href="#warn.code.registration">Registrations</a></li> 647 663 </ul> 648 664 </li> 665 <li><a href="#rfc.section.7.3">7.3</a> <a href="#header.field.registration">Header Field Registration</a></li> 649 666 </ul> 650 667 </li> 651 <li><a href="#rfc.section.8">8.</a> <a href="#history.lists">History Lists</a></li> 652 <li><a href="#rfc.section.9">9.</a> <a href="#iana.considerations">IANA Considerations</a><ul> 653 <li><a href="#rfc.section.9.1">9.1</a> <a href="#cache.directive.registry">Cache Directive Registry</a><ul> 654 <li><a href="#rfc.section.9.1.1">9.1.1</a> <a href="#cache.directive.registry.procedure">Procedure</a></li> 655 <li><a href="#rfc.section.9.1.2">9.1.2</a> <a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li> 656 <li><a href="#rfc.section.9.1.3">9.1.3</a> <a href="#cache.directive.registration">Registrations</a></li> 657 </ul> 658 </li> 659 <li><a href="#rfc.section.9.2">9.2</a> <a href="#warn.code.registry">Warn Code Registry</a><ul> 660 <li><a href="#rfc.section.9.2.1">9.2.1</a> <a href="#warn.code.registry.procedure">Procedure</a></li> 661 <li><a href="#rfc.section.9.2.2">9.2.2</a> <a href="#warn.code.registration">Registrations</a></li> 662 </ul> 663 </li> 664 <li><a href="#rfc.section.9.3">9.3</a> <a href="#header.field.registration">Header Field Registration</a></li> 665 </ul> 666 </li> 667 <li><a href="#rfc.section.10">10.</a> <a href="#security.considerations">Security Considerations</a></li> 668 <li><a href="#rfc.section.11">11.</a> <a href="#acks">Acknowledgments</a></li> 669 <li><a href="#rfc.section.12">12.</a> <a href="#rfc.references">References</a><ul> 670 <li><a href="#rfc.section.12.1">12.1</a> <a href="#rfc.references.1">Normative References</a></li> 671 <li><a href="#rfc.section.12.2">12.2</a> <a href="#rfc.references.2">Informative References</a></li> 668 <li><a href="#rfc.section.8">8.</a> <a href="#security.considerations">Security Considerations</a></li> 669 <li><a href="#rfc.section.9">9.</a> <a href="#acks">Acknowledgments</a></li> 670 <li><a href="#rfc.section.10">10.</a> <a href="#rfc.references">References</a><ul> 671 <li><a href="#rfc.section.10.1">10.1</a> <a href="#rfc.references.1">Normative References</a></li> 672 <li><a href="#rfc.section.10.2">10.2</a> <a href="#rfc.references.2">Informative References</a></li> 672 673 </ul> 673 674 </li> … … 747 748 <li>The request method is understood by the cache and defined as being cacheable, and</li> 748 749 <li>the response status code is understood by the cache, and</li> 749 <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 7.2</a>) does not appear in request or response header fields, and750 </li> 751 <li>the "private" cache response directive (see <a href="#cache-response-directive.private" title="private">Section 7.2.2.6</a>) does not appear in the response, if the cache is shared, and750 <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 5.2</a>) does not appear in request or response header fields, and 751 </li> 752 <li>the "private" cache response directive (see <a href="#cache-response-directive.private" title="private">Section 5.2.2.6</a>) does not appear in the response, if the cache is shared, and 752 753 </li> 753 754 <li>the <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a>), and … … 755 756 <li>the response either: 756 757 <ul> 757 <li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 7.3</a>), or758 <li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 5.3</a>), or 758 759 </li> 759 <li>contains a max-age response cache directive (see <a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.8</a>), or760 <li>contains a max-age response cache directive (see <a href="#cache-response-directive.max-age" title="max-age">Section 5.2.2.8</a>), or 760 761 </li> 761 <li>contains a s-maxage response cache directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.9</a>) and the cache is shared, or762 <li>contains a s-maxage response cache directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section 5.2.2.9</a>) and the cache is shared, or 762 763 </li> 763 <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a>) that allows it to be cached, or764 <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 5.2.3</a>) that allows it to be cached, or 764 765 </li> 765 766 <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a>), or 766 767 </li> 767 <li>contains a public response cache directive (see <a href="#cache-response-directive.public" title="public">Section 7.2.2.5</a>).768 <li>contains a public response cache directive (see <a href="#cache-response-directive.public" title="public">Section 5.2.2.5</a>). 768 769 </li> 769 770 </ul> 770 771 </li> 771 772 </ul> 772 <p id="rfc.section.3.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a>.773 <p id="rfc.section.3.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 5.2.3</a>. 773 774 </p> 774 775 <p id="rfc.section.3.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all … … 789 790 <p id="rfc.section.3.2.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response. 790 791 </p> 791 <p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>) have such an effect: must-revalidate, public, s-maxage.792 <p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 5.2.2</a>) have such an effect: must-revalidate, public, s-maxage. 792 793 </p> 793 794 <p id="rfc.section.3.2.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be … … 803 804 </p> 804 805 <ul> 805 <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 7.5</a>);806 <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 5.5</a>); 806 807 </li> 807 808 <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and, … … 819 820 <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), and 820 821 </li> 821 <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 7.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section 4.3</a>), and822 </li> 823 <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section 4.3</a>), and822 <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 5.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 5.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section 4.3</a>), and 823 </li> 824 <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section 5.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section 4.3</a>), and 824 825 </li> 825 826 <li>the stored response is either: … … 834 835 </li> 835 836 </ul> 836 <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a>.837 </p> 838 <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 7.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>.837 <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 5.2.3</a>. 838 </p> 839 <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 5.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>. 839 840 </p> 840 841 <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request 841 842 and having received a corresponding response. 842 843 </p> 843 <p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation .after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>.844 <p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation" title="Invalidation">Section 4.4</a>. 844 845 </p> 845 846 <p id="rfc.section.4.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate … … 893 894 </p> 894 895 <p id="rfc.section.4.2.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, 895 using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 7.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation896 using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 5.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section 5.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation 896 897 is not likely to change in a semantically significant way before the expiration time is reached. 897 898 </p> … … 908 909 </p> 909 910 <p id="rfc.section.4.2.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the 910 corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>).911 corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 5.2.1</a>). 911 912 </p> 912 913 <p id="rfc.section.4.2.p.11">When calculating freshness, to avoid common problems in date parsing:</p> … … 923 924 </ul> 924 925 <p id="rfc.section.4.2.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload 925 a resource. See <a href="#history.lists" title="History Lists">Section 8</a> for an explanation of the difference between caches and history mechanisms.926 a resource. See <a href="#history.lists" title="History Lists">Section 6</a> for an explanation of the difference between caches and history mechanisms. 926 927 </p> 927 928 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3> 928 929 <p id="rfc.section.4.2.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p> 929 930 <ul> 930 <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.9</a>) is present, use its value, or931 </li> 932 <li>If the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.8</a>) is present, use its value, or933 </li> 934 <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 7.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or931 <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 5.2.2.9</a>) is present, use its value, or 932 </li> 933 <li>If the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section 5.2.2.8</a>) is present, use its value, or 934 </li> 935 <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 5.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or 935 936 </li> 936 937 <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a>. … … 973 974 </p> 974 975 <ul class="empty"> 975 <li>The term "age_value" denotes the value of the <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section 7.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.976 <li>The term "age_value" denotes the value of the <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section 5.1</a>), in a form appropriate for arithmetic operation; or 0, if not available. 976 977 </li> 977 978 </ul> … … 1025 1026 <p id="rfc.section.4.2.4.p.2">A cache <em class="bcp14">MUST NOT</em> generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 1026 1027 directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 1027 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>).1028 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 5.2.2</a>). 1028 1029 </p> 1029 1030 <p id="rfc.section.4.2.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) 1030 or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>).1031 </p> 1032 <p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.1031 or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 5.2.1</a>). 1032 </p> 1033 <p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 5.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected. 1033 1034 </p> 1034 1035 <div id="rfc.iref.f.3"></div> … … 1038 1039 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="validation.model" href="#validation.model">Validation</a></h2> 1039 1040 <p id="rfc.section.4.3.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 1040 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 1041 update it. This process is known as "validating" or "revalidating" the stored response. 1041 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the next inbound server an opportunity to select a valid stored response to use, updating 1042 the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as "validating" 1043 or "revalidating" the stored response. 1042 1044 </p> 1043 1045 <div id="rfc.iref.v.1"></div> 1044 <p id="rfc.section.4.3.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of 1045 the resource. 1046 </p> 1047 <p id="rfc.section.4.3.p.3">One such validator is the <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field, whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) stored response, if available. 1048 </p> 1049 <p id="rfc.section.4.3.p.4">Another is the <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field, whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from relevant responses stored for the primary cache key, if present. However, if any of the stored responses 1050 contains only partial content, the cache ought not include its entity-tag in the If-None-Match header field unless the request 1051 is for a range that would be fully satisfied by that stored response. 1052 </p> 1053 <p id="rfc.section.4.3.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p> 1054 <p id="rfc.section.4.3.p.6"></p> 1046 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="validation.sent" href="#validation.sent">Sending a Validation Request</a></h3> 1047 <p id="rfc.section.4.3.1.p.1">When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing <dfn>validator</dfn> metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent 1048 to a current representation of the resource. 1049 </p> 1050 <p id="rfc.section.4.3.1.p.2">One such validator is the timestamp given in a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), which can be used in an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field for response validation, or in an <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field for representation selection (i.e., the client is referring specifically to a previously obtained representation 1051 with that timestamp). 1052 </p> 1053 <p id="rfc.section.4.3.1.p.3">Another validator is the entity-tag given in an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). One or more entity-tags, indicating one or more stored responses, can be used in an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field for response validation, or in an <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a> or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field for representation selection (i.e., the client is referring specifically to one or more previously obtained representations 1054 with the listed entity-tags). 1055 </p> 1056 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="validation.received" href="#validation.received">Handling a Received Validation Request</a></h3> 1057 <p id="rfc.section.4.3.2.p.1">Each client in the request chain may have its own cache, so it is common for a cache at an intermediary or origin server to 1058 receive conditional requests from other (outbound) caches. Likewise, some user agents make use of conditional requests to 1059 limit data transfers to recently modified representations or to complete the transfer of partially retrieved representations. 1060 </p> 1061 <p id="rfc.section.4.3.2.p.2">If the request semantics can be satisfied with a cached response and a recipient cache has at least one response stored for 1062 this primary cache key, the cache <em class="bcp14">MUST</em> evaluate received precondition header fields as part of its selection process for determining a suitable response. A cache <em class="bcp14">MUST NOT</em> evaluate received precondition header fields in a request with semantics that cannot be satisfied with a cached response, 1063 or for which the cache has no prior stored responses, since such preconditions are intended for some other (inbound) server. 1064 </p> 1065 <p id="rfc.section.4.3.2.p.3">The proper evaluation of conditional requests by a cache depends on the received precondition header fields and their precedence, 1066 as defined in <a href="p4-conditional.html#precedence" title="Precedence">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>. 1067 </p> 1068 <p id="rfc.section.4.3.2.p.4">A request containing an <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a> header field (<a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to receive an error response if the cache has a stored response that cannot be used to answer 1069 this request. The cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.412" class="smpl">412 (Precondition Failed)</a> response if the field-value is "*" and no suitable response is stored, or if the field-value is a list of entity-tags and 1070 none of them match the entity-tag of a suitable stored response. Otherwise, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most recent of its matching stored responses to satisfy the request. 1071 </p> 1072 <p id="rfc.section.4.3.2.p.5">A request containing an <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field (<a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to receive an error response if the cache has a stored response that cannot be used to answer 1073 this request. The cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.412" class="smpl">412 (Precondition Failed)</a> response if one of the following is true: 1) a stored response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp. 1074 Otherwise, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most recent of its matching stored responses to satisfy the request. 1075 </p> 1076 <p id="rfc.section.4.3.2.p.6">A request containing an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field (<a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to validate one or more of its stored responses. If the field-value is "*" and any suitable 1077 response is stored, or the field-value is a list of entity-tags and at least one of them match the entity-tag of a suitable 1078 stored response, the cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response using the most suitable of those matching responses as the selected representation. Otherwise, if the cache has one 1079 or more suitable stored responses that do not match the condition, the cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response that reuses the most suitable of those stored responses to satisfy the request. Finally, if the cache has no suitable 1080 stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server; if the received condition contains a list of entity-tags and the 1081 cache has its own set of stored responses for that primary cache key, the cache <em class="bcp14">SHOULD</em> take the union of the received set with the set of entity-tags for its own stored set of responses (fresh or stale) and generate 1082 an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field containing that union when it forwards the request toward the origin server. However, if a stored responses contains 1083 only partial content, the cache <em class="bcp14">MUST NOT</em> include its entity-tag in the union unless the request is for a range that would be fully satisfied by that stored response. 1084 </p> 1085 <p id="rfc.section.4.3.2.p.7">A request containing an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field (<a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) indicates that the client wants to validate one or more of its stored responses by modification date if the stored responses 1086 have no entity-tag or the recipient does not implement <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>. The cache <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response, reusing the most recent of its stored responses to satisfy the request, if one of the following is true: 1) a stored 1087 response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field-value that is more recent than the conditional timestamp; 2) no <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> field is present, but a stored response has a <a href="p2-semantics.html#header.date" class="smpl">Date</a> field-value that is more recent than the conditional timestamp; or, 3) neither <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> nor <a href="p2-semantics.html#header.date" class="smpl">Date</a> is present, but the cache recorded a stored response as having been received at a time more recent than the conditional timestamp. 1088 Otherwise, if the cache has one or more suitable stored responses, the cache <em class="bcp14">MUST</em> generate a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response using the most recent of its suitable stored responses as the selected representation. Finally, if the cache has 1089 no suitable stored responses, the cache <em class="bcp14">SHOULD</em> forward the conditional request toward the origin server. 1090 </p> 1091 <p id="rfc.section.4.3.2.p.8">A cache that implements partial responses to range requests, as defined in <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, also needs to evaluate a received <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) in respect to its selected stored response. 1092 </p> 1093 <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="validation.response" href="#validation.response">Handling a Validation Response</a></h3> 1094 <p id="rfc.section.4.3.3.p.1">Cache handling of a response to a conditional request is dependent upon its status code:</p> 1095 <p id="rfc.section.4.3.3.p.2"></p> 1055 1096 <ul> 1056 <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3. 1</a>.1097 <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3.4</a>. 1057 1098 </li> 1058 1099 <li>A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request 1059 is suitable. Instead, the cache canuse the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).1100 is suitable. Instead, the cache <em class="bcp14">MUST</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s). 1060 1101 </li> 1061 1102 <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as 1062 if the server failed to respond. In the latter case, it cansend a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>).1063 </li> 1064 </ul> 1065 <h3 id="rfc.section.4.3. 1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>1066 <p id="rfc.section.4.3. 1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response1103 if the server failed to respond. In the latter case, the cache <em class="bcp14">MAY</em> send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>). 1104 </li> 1105 </ul> 1106 <h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a> <a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3> 1107 <p id="rfc.section.4.3.4.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response 1067 1108 and then update the stored response(s) with the new information provided in the <a href="p4-conditional.html#status.304" class="smpl">304</a> response. 1068 1109 </p> 1069 1110 <div id="rfc.iref.s.3"></div> 1070 <p id="rfc.section.4.3. 1.p.2">The stored response to update is identified by using the first match (if any) of: </p>1111 <p id="rfc.section.4.3.4.p.2">The stored response to update is identified by using the first match (if any) of: </p> 1071 1112 <ul> 1072 <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4. 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same1113 <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same 1073 1114 strong validator are selected. If none of the stored responses contain the same strong validator, then the cache <em class="bcp14">MUST NOT</em> use the new response to update any stored responses. 1074 1115 </li> … … 1081 1122 </li> 1082 1123 </ul> 1083 <p id="rfc.section.4.3. 1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:1124 <p id="rfc.section.4.3.4.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 1084 1125 </p> 1085 1126 <ul> 1086 <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 7.5</a>);1127 <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 5.5</a>); 1087 1128 </li> 1088 1129 <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and, … … 1091 1132 </li> 1092 1133 </ul> 1093 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="head.effects" href="#head.effects">Updating Caches with HEAD Responses</a></h1> 1094 <p id="rfc.section.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks 1095 a body. This property of HEAD responses is used to both invalidate and update cached GET responses. 1096 </p> 1097 <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale. 1098 </p> 1099 <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 1134 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="head.effects" href="#head.effects">Freshening Responses via HEAD</a></h3> 1135 <p id="rfc.section.4.3.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks 1136 a body. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional 1137 GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the 1138 representation body is not desired even if it has changed. 1139 </p> 1140 <p id="rfc.section.4.3.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale. 1141 </p> 1142 <p id="rfc.section.4.3.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 1100 1143 </p> 1101 1144 <ul> 1102 <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 7.5</a>);1145 <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 5.5</a>); 1103 1146 </li> 1104 1147 <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and, 1105 1148 </li> 1106 <li>use other header fields provided in the response to replace all instances of the corresponding header fields in the stored1149 <li>use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored 1107 1150 response. 1108 1151 </li> 1109 1152 </ul> 1110 <h 1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1>1111 <p id="rfc.section. 6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them1153 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="invalidation" href="#invalidation">Invalidation</a></h2> 1154 <p id="rfc.section.4.4.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 1112 1155 to keep their contents up-to-date. 1113 1156 </p> 1114 <p id="rfc.section. 6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.1115 </p> 1116 <p id="rfc.section. 6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks.1117 </p> 1118 <p id="rfc.section. 6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.1119 </p> 1120 <p id="rfc.section. 6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,1157 <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received. 1158 </p> 1159 <p id="rfc.section.4.4.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1160 </p> 1161 <p id="rfc.section.4.4.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. 1162 </p> 1163 <p id="rfc.section.4.4.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI, 1121 1164 or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent 1122 1165 request. 1123 1166 </p> 1124 <p id="rfc.section. 6.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might1167 <p id="rfc.section.4.4.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might 1125 1168 invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it 1126 1169 has not. 1127 1170 </p> 1128 <h1 id="rfc.section. 7"><a href="#rfc.section.7">7.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>1129 <p id="rfc.section. 7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>1171 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 1172 <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> 1130 1173 <div id="rfc.iref.a.2"></div> 1131 <h2 id="rfc.section. 7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.age" href="#header.age">Age</a></h2>1132 <p id="rfc.section. 7.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully1174 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.age" href="#header.age">Age</a></h2> 1175 <p id="rfc.section.5.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully 1133 1176 validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>. 1134 1177 </p> 1135 1178 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#header.age" class="smpl">Age</a> = <a href="#delta-seconds" class="smpl">delta-seconds</a> 1136 </pre><p id="rfc.section. 7.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>).1137 </p> 1138 <p id="rfc.section. 7.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not1179 </pre><p id="rfc.section.5.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>). 1180 </p> 1181 <p id="rfc.section.5.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not 1139 1182 true, since HTTP/1.0 caches might not implement the Age header field. 1140 1183 </p> 1141 1184 <div id="rfc.iref.c.5"></div> 1142 <h2 id="rfc.section. 7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>1143 <p id="rfc.section. 7.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives1185 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> 1186 <p id="rfc.section.5.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives 1144 1187 are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given 1145 1188 in the response. 1146 1189 </p> 1147 <p id="rfc.section. 7.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.1148 </p> 1149 <div class="note" id="rfc.section. 7.2.p.3">1190 <p id="rfc.section.5.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section 5.2.3</a> for information about how Cache-Control directives defined elsewhere are handled. 1191 </p> 1192 <div class="note" id="rfc.section.5.2.p.3"> 1150 1193 <p><b>Note:</b> Some HTTP/1.0 caches might not implement Cache-Control. 1151 1194 </p> 1152 1195 </div> 1153 <p id="rfc.section. 7.2.p.4">A proxy, whether or not it implements a cache, <em class="bcp14">MUST</em> pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives1196 <p id="rfc.section.5.2.p.4">A proxy, whether or not it implements a cache, <em class="bcp14">MUST</em> pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives 1154 1197 might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific 1155 1198 cache. 1156 1199 </p> 1157 <p id="rfc.section. 7.2.p.5">Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use1200 <p id="rfc.section.5.2.p.5">Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use 1158 1201 both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both 1159 1202 forms, even if one is documented to be preferred. For any directive not defined by this specification, recipients <em class="bcp14">MUST</em> accept both forms. … … 1162 1205 1163 1206 <a href="#header.cache-control" class="smpl">cache-directive</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ] 1164 </pre><p id="rfc.section. 7.2.p.7">For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.</p>1165 <h3 id="rfc.section. 7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>1207 </pre><p id="rfc.section.5.2.p.7">For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.</p> 1208 <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a> <a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3> 1166 1209 <div id="rfc.iref.m.1"></div> 1167 <h4 id="rfc.section. 7.2.1.1"><a href="#rfc.section.7.2.1.1">7.2.1.1</a> <a id="cache-request-directive.max-age" href="#cache-request-directive.max-age">max-age</a></h4>1168 <p id="rfc.section. 7.2.1.1.p.1">Argument syntax: </p>1210 <h4 id="rfc.section.5.2.1.1"><a href="#rfc.section.5.2.1.1">5.2.1.1</a> <a id="cache-request-directive.max-age" href="#cache-request-directive.max-age">max-age</a></h4> 1211 <p id="rfc.section.5.2.1.1.p.1">Argument syntax: </p> 1169 1212 <ul class="empty"> 1170 1213 <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1171 1214 </li> 1172 1215 </ul> 1173 <p id="rfc.section. 7.2.1.1.p.2">The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the1216 <p id="rfc.section.5.2.1.1.p.2">The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the 1174 1217 specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a 1175 1218 stale response. 1176 1219 </p> 1177 <p id="rfc.section. 7.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.1220 <p id="rfc.section.5.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form. 1178 1221 </p> 1179 1222 <div id="rfc.iref.m.2"></div> 1180 <h4 id="rfc.section. 7.2.1.2"><a href="#rfc.section.7.2.1.2">7.2.1.2</a> <a id="cache-request-directive.max-stale" href="#cache-request-directive.max-stale">max-stale</a></h4>1181 <p id="rfc.section. 7.2.1.2.p.1">Argument syntax: </p>1223 <h4 id="rfc.section.5.2.1.2"><a href="#rfc.section.5.2.1.2">5.2.1.2</a> <a id="cache-request-directive.max-stale" href="#cache-request-directive.max-stale">max-stale</a></h4> 1224 <p id="rfc.section.5.2.1.2.p.1">Argument syntax: </p> 1182 1225 <ul class="empty"> 1183 1226 <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1184 1227 </li> 1185 1228 </ul> 1186 <p id="rfc.section. 7.2.1.2.p.2">The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness1229 <p id="rfc.section.5.2.1.2.p.2">The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness 1187 1230 lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness 1188 1231 lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing 1189 1232 to accept a stale response of any age. 1190 1233 </p> 1191 <p id="rfc.section. 7.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.1234 <p id="rfc.section.5.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form. 1192 1235 </p> 1193 1236 <div id="rfc.iref.m.3"></div> 1194 <h4 id="rfc.section. 7.2.1.3"><a href="#rfc.section.7.2.1.3">7.2.1.3</a> <a id="cache-request-directive.min-fresh" href="#cache-request-directive.min-fresh">min-fresh</a></h4>1195 <p id="rfc.section. 7.2.1.3.p.1">Argument syntax: </p>1237 <h4 id="rfc.section.5.2.1.3"><a href="#rfc.section.5.2.1.3">5.2.1.3</a> <a id="cache-request-directive.min-fresh" href="#cache-request-directive.min-fresh">min-fresh</a></h4> 1238 <p id="rfc.section.5.2.1.3.p.1">Argument syntax: </p> 1196 1239 <ul class="empty"> 1197 1240 <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1198 1241 </li> 1199 1242 </ul> 1200 <p id="rfc.section. 7.2.1.3.p.2">The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no1243 <p id="rfc.section.5.2.1.3.p.2">The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no 1201 1244 less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh 1202 1245 for at least the specified number of seconds. 1203 1246 </p> 1204 <p id="rfc.section. 7.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.1247 <p id="rfc.section.5.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form. 1205 1248 </p> 1206 1249 <div id="rfc.iref.n.1"></div> 1207 <h4 id="rfc.section. 7.2.1.4"><a href="#rfc.section.7.2.1.4">7.2.1.4</a> <a id="cache-request-directive.no-cache" href="#cache-request-directive.no-cache">no-cache</a></h4>1208 <p id="rfc.section. 7.2.1.4.p.1">The "no-cache" request directive indicates that a cache <em class="bcp14">MUST NOT</em> use a stored response to satisfy the request without successful validation on the origin server.1250 <h4 id="rfc.section.5.2.1.4"><a href="#rfc.section.5.2.1.4">5.2.1.4</a> <a id="cache-request-directive.no-cache" href="#cache-request-directive.no-cache">no-cache</a></h4> 1251 <p id="rfc.section.5.2.1.4.p.1">The "no-cache" request directive indicates that a cache <em class="bcp14">MUST NOT</em> use a stored response to satisfy the request without successful validation on the origin server. 1209 1252 </p> 1210 1253 <div id="rfc.iref.n.2"></div> 1211 <h4 id="rfc.section. 7.2.1.5"><a href="#rfc.section.7.2.1.5">7.2.1.5</a> <a id="cache-request-directive.no-store" href="#cache-request-directive.no-store">no-store</a></h4>1212 <p id="rfc.section. 7.2.1.5.p.1">The "no-store" request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.1213 </p> 1214 <p id="rfc.section. 7.2.1.5.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches1254 <h4 id="rfc.section.5.2.1.5"><a href="#rfc.section.5.2.1.5">5.2.1.5</a> <a id="cache-request-directive.no-store" href="#cache-request-directive.no-store">no-store</a></h4> 1255 <p id="rfc.section.5.2.1.5.p.1">The "no-store" request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 1256 </p> 1257 <p id="rfc.section.5.2.1.5.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches 1215 1258 might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. 1216 1259 </p> 1217 <p id="rfc.section. 7.2.1.5.p.3">Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply1260 <p id="rfc.section.5.2.1.5.p.3">Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply 1218 1261 to the already stored response. 1219 1262 </p> 1220 1263 <div id="rfc.iref.n.3"></div> 1221 <h4 id="rfc.section. 7.2.1.6"><a href="#rfc.section.7.2.1.6">7.2.1.6</a> <a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4>1222 <p id="rfc.section. 7.2.1.6.p.1">The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.1264 <h4 id="rfc.section.5.2.1.6"><a href="#rfc.section.5.2.1.6">5.2.1.6</a> <a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4> 1265 <p id="rfc.section.5.2.1.6.p.1">The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 1223 1266 </p> 1224 1267 <div id="rfc.iref.o.1"></div> 1225 <h4 id="rfc.section. 7.2.1.7"><a href="#rfc.section.7.2.1.7">7.2.1.7</a> <a id="cache-request-directive.only-if-cached" href="#cache-request-directive.only-if-cached">only-if-cached</a></h4>1226 <p id="rfc.section. 7.2.1.7.p.1">The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this1268 <h4 id="rfc.section.5.2.1.7"><a href="#rfc.section.5.2.1.7">5.2.1.7</a> <a id="cache-request-directive.only-if-cached" href="#cache-request-directive.only-if-cached">only-if-cached</a></h4> 1269 <p id="rfc.section.5.2.1.7.p.1">The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this 1227 1270 directive, a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a <a href="p2-semantics.html#status.504" class="smpl">504 (Gateway 1228 1271 Timeout)</a> status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache <em class="bcp14">MAY</em> forward such a request within that group of caches. 1229 1272 </p> 1230 <h3 id="rfc.section. 7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>1273 <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a> <a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3> 1231 1274 <div id="rfc.iref.m.4"></div> 1232 <h4 id="rfc.section. 7.2.2.1"><a href="#rfc.section.7.2.2.1">7.2.2.1</a> <a id="cache-response-directive.must-revalidate" href="#cache-response-directive.must-revalidate">must-revalidate</a></h4>1233 <p id="rfc.section. 7.2.2.1.p.1">The "must-revalidate" response directive indicates that once it has become stale, a cache <em class="bcp14">MUST NOT</em> use the response to satisfy subsequent requests without successful validation on the origin server.1234 </p> 1235 <p id="rfc.section. 7.2.2.1.p.2">The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances1275 <h4 id="rfc.section.5.2.2.1"><a href="#rfc.section.5.2.2.1">5.2.2.1</a> <a id="cache-response-directive.must-revalidate" href="#cache-response-directive.must-revalidate">must-revalidate</a></h4> 1276 <p id="rfc.section.5.2.2.1.p.1">The "must-revalidate" response directive indicates that once it has become stale, a cache <em class="bcp14">MUST NOT</em> use the response to satisfy subsequent requests without successful validation on the origin server. 1277 </p> 1278 <p id="rfc.section.5.2.2.1.p.2">The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances 1236 1279 a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.504" class="smpl">504 (Gateway Timeout)</a> response. 1237 1280 </p> 1238 <p id="rfc.section. 7.2.2.1.p.3">The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation1281 <p id="rfc.section.5.2.2.1.p.3">The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation 1239 1282 could result in incorrect operation, such as a silently unexecuted financial transaction. 1240 1283 </p> 1241 1284 <div id="rfc.iref.n.4"></div> 1242 <h4 id="rfc.section. 7.2.2.2"><a href="#rfc.section.7.2.2.2">7.2.2.2</a> <a id="cache-response-directive.no-cache" href="#cache-response-directive.no-cache">no-cache</a></h4>1243 <p id="rfc.section. 7.2.2.2.p.1">Argument syntax: </p>1285 <h4 id="rfc.section.5.2.2.2"><a href="#rfc.section.5.2.2.2">5.2.2.2</a> <a id="cache-response-directive.no-cache" href="#cache-response-directive.no-cache">no-cache</a></h4> 1286 <p id="rfc.section.5.2.2.2.p.1">Argument syntax: </p> 1244 1287 <ul class="empty"> 1245 1288 <li>#<a href="#imported.abnf" class="smpl">field-name</a> 1246 1289 </li> 1247 1290 </ul> 1248 <p id="rfc.section. 7.2.2.2.p.2">The "no-cache" response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to1291 <p id="rfc.section.5.2.2.2.p.2">The "no-cache" response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to 1249 1292 prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send 1250 1293 stale responses. 1251 1294 </p> 1252 <p id="rfc.section. 7.2.2.2.p.3">If the no-cache response directive specifies one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields1295 <p id="rfc.section.5.2.2.2.p.3">If the no-cache response directive specifies one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields 1253 1296 in the response that have the field-name(s) listed <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin 1254 1297 server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. 1255 1298 </p> 1256 <p id="rfc.section. 7.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>1257 <p id="rfc.section. 7.2.2.2.p.5"><b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive.1299 <p id="rfc.section.5.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p> 1300 <p id="rfc.section.5.2.2.2.p.5"><b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive. 1258 1301 Also, no-cache response directives with field-names are often handled by caches as if an unqualified no-cache directive was 1259 1302 received; i.e., the special handling for the qualified form is not widely implemented. 1260 1303 </p> 1261 <p id="rfc.section. 7.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).1304 <p id="rfc.section.5.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists). 1262 1305 </p> 1263 1306 <div id="rfc.iref.n.5"></div> 1264 <h4 id="rfc.section. 7.2.2.3"><a href="#rfc.section.7.2.2.3">7.2.2.3</a> <a id="cache-response-directive.no-store" href="#cache-response-directive.no-store">no-store</a></h4>1265 <p id="rfc.section. 7.2.2.3.p.1">The "no-store" response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.1266 </p> 1267 <p id="rfc.section. 7.2.2.3.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches1307 <h4 id="rfc.section.5.2.2.3"><a href="#rfc.section.5.2.2.3">5.2.2.3</a> <a id="cache-response-directive.no-store" href="#cache-response-directive.no-store">no-store</a></h4> 1308 <p id="rfc.section.5.2.2.3.p.1">The "no-store" response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 1309 </p> 1310 <p id="rfc.section.5.2.2.3.p.2">This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches 1268 1311 might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. 1269 1312 </p> 1270 1313 <div id="rfc.iref.n.6"></div> 1271 <h4 id="rfc.section. 7.2.2.4"><a href="#rfc.section.7.2.2.4">7.2.2.4</a> <a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4>1272 <p id="rfc.section. 7.2.2.4.p.1">The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.1314 <h4 id="rfc.section.5.2.2.4"><a href="#rfc.section.5.2.2.4">5.2.2.4</a> <a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4> 1315 <p id="rfc.section.5.2.2.4.p.1">The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> transform the payload, as defined in <a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 1273 1316 </p> 1274 1317 <div id="rfc.iref.p.2"></div> 1275 <h4 id="rfc.section. 7.2.2.5"><a href="#rfc.section.7.2.2.5">7.2.2.5</a> <a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4>1276 <p id="rfc.section. 7.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section 3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined1318 <h4 id="rfc.section.5.2.2.5"><a href="#rfc.section.5.2.2.5">5.2.2.5</a> <a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4> 1319 <p id="rfc.section.5.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section 3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined 1277 1320 as cacheable.) 1278 1321 </p> 1279 1322 <div id="rfc.iref.p.3"></div> 1280 <h4 id="rfc.section. 7.2.2.6"><a href="#rfc.section.7.2.2.6">7.2.2.6</a> <a id="cache-response-directive.private" href="#cache-response-directive.private">private</a></h4>1281 <p id="rfc.section. 7.2.2.6.p.1">Argument syntax: </p>1323 <h4 id="rfc.section.5.2.2.6"><a href="#rfc.section.5.2.2.6">5.2.2.6</a> <a id="cache-response-directive.private" href="#cache-response-directive.private">private</a></h4> 1324 <p id="rfc.section.5.2.2.6.p.1">Argument syntax: </p> 1282 1325 <ul class="empty"> 1283 1326 <li>#<a href="#imported.abnf" class="smpl">field-name</a> 1284 1327 </li> 1285 1328 </ul> 1286 <p id="rfc.section. 7.2.2.6.p.2">The "private" response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private cache <em class="bcp14">MAY</em> store the response and reuse it for later requests, even if the response would normally be non-cacheable.1287 </p> 1288 <p id="rfc.section. 7.2.2.6.p.3">If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated1329 <p id="rfc.section.5.2.2.6.p.2">The "private" response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private cache <em class="bcp14">MAY</em> store the response and reuse it for later requests, even if the response would normally be non-cacheable. 1330 </p> 1331 <p id="rfc.section.5.2.2.6.p.3">If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated 1289 1332 with the listed response header fields. That is, a shared cache <em class="bcp14">MUST NOT</em> store the specified field-names(s), whereas it <em class="bcp14">MAY</em> store the remainder of the response message. 1290 1333 </p> 1291 <p id="rfc.section. 7.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>1292 <p id="rfc.section. 7.2.2.6.p.5"><b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message1334 <p id="rfc.section.5.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p> 1335 <p id="rfc.section.5.2.2.6.p.5"><b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message 1293 1336 content. Also, private response directives with field-names are often handled by caches as if an unqualified private directive 1294 1337 was received; i.e., the special handling for the qualified form is not widely implemented. 1295 1338 </p> 1296 <p id="rfc.section. 7.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).1339 <p id="rfc.section.5.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists). 1297 1340 </p> 1298 1341 <div id="rfc.iref.p.4"></div> 1299 <h4 id="rfc.section. 7.2.2.7"><a href="#rfc.section.7.2.2.7">7.2.2.7</a> <a id="cache-response-directive.proxy-revalidate" href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></h4>1300 <p id="rfc.section. 7.2.2.7.p.1">The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does1342 <h4 id="rfc.section.5.2.2.7"><a href="#rfc.section.5.2.2.7">5.2.2.7</a> <a id="cache-response-directive.proxy-revalidate" href="#cache-response-directive.proxy-revalidate">proxy-revalidate</a></h4> 1343 <p id="rfc.section.5.2.2.7.p.1">The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does 1301 1344 not apply to private caches. 1302 1345 </p> 1303 1346 <div id="rfc.iref.m.5"></div> 1304 <h4 id="rfc.section. 7.2.2.8"><a href="#rfc.section.7.2.2.8">7.2.2.8</a> <a id="cache-response-directive.max-age" href="#cache-response-directive.max-age">max-age</a></h4>1305 <p id="rfc.section. 7.2.2.8.p.1">Argument syntax: </p>1347 <h4 id="rfc.section.5.2.2.8"><a href="#rfc.section.5.2.2.8">5.2.2.8</a> <a id="cache-response-directive.max-age" href="#cache-response-directive.max-age">max-age</a></h4> 1348 <p id="rfc.section.5.2.2.8.p.1">Argument syntax: </p> 1306 1349 <ul class="empty"> 1307 1350 <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1308 1351 </li> 1309 1352 </ul> 1310 <p id="rfc.section. 7.2.2.8.p.2">The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified1353 <p id="rfc.section.5.2.2.8.p.2">The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified 1311 1354 number of seconds. 1312 1355 </p> 1313 <p id="rfc.section. 7.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.1356 <p id="rfc.section.5.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form. 1314 1357 </p> 1315 1358 <div id="rfc.iref.s.4"></div> 1316 <h4 id="rfc.section. 7.2.2.9"><a href="#rfc.section.7.2.2.9">7.2.2.9</a> <a id="cache-response-directive.s-maxage" href="#cache-response-directive.s-maxage">s-maxage</a></h4>1317 <p id="rfc.section. 7.2.2.9.p.1">Argument syntax: </p>1359 <h4 id="rfc.section.5.2.2.9"><a href="#rfc.section.5.2.2.9">5.2.2.9</a> <a id="cache-response-directive.s-maxage" href="#cache-response-directive.s-maxage">s-maxage</a></h4> 1360 <p id="rfc.section.5.2.2.9.p.1">Argument syntax: </p> 1318 1361 <ul class="empty"> 1319 1362 <li><a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1320 1363 </li> 1321 1364 </ul> 1322 <p id="rfc.section. 7.2.2.9.p.2">The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides1365 <p id="rfc.section.5.2.2.9.p.2">The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides 1323 1366 the maximum age specified by either the max-age directive or the <a href="#header.expires" class="smpl">Expires</a> header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive. 1324 1367 </p> 1325 <p id="rfc.section. 7.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.1326 </p> 1327 <h3 id="rfc.section. 7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>1328 <p id="rfc.section. 7.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional1368 <p id="rfc.section.5.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form. 1369 </p> 1370 <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> 1371 <p id="rfc.section.5.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional 1329 1372 value. 1330 1373 </p> 1331 <p id="rfc.section. 7.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics1374 <p id="rfc.section.5.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics 1332 1375 of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. 1333 1376 </p> 1334 <p id="rfc.section. 7.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive1377 <p id="rfc.section.5.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive 1335 1378 will default to the behavior specified by the standard directive, and those that understand the new directive will recognize 1336 1379 it as modifying the requirements associated with the standard directive. In this way, extensions to the cache-control directives 1337 1380 can be made without requiring changes to the base protocol. 1338 1381 </p> 1339 <p id="rfc.section. 7.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,1382 <p id="rfc.section.5.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version, 1340 1383 obeying certain extensions, and ignoring all directives that it does not understand. 1341 1384 </p> 1342 <p id="rfc.section. 7.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.1385 <p id="rfc.section.5.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive. 1343 1386 We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the 1344 1387 community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to … … 1346 1389 </p> 1347 1390 <div id="rfc.figure.u.8"></div><pre class="text"> Cache-Control: private, community="UCI" 1348 </pre><p id="rfc.section. 7.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since1391 </pre><p id="rfc.section.5.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since 1349 1392 it will also see and understand the private directive and thus default to the safe behavior. 1350 1393 </p> 1351 <p id="rfc.section. 7.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache1394 <p id="rfc.section.5.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache 1352 1395 will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain 1353 1396 minimally correct even if the cache does not understand the extension(s). 1354 1397 </p> 1355 1398 <div id="rfc.iref.e.2"></div> 1356 <h2 id="rfc.section. 7.3"><a href="#rfc.section.7.3">7.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2>1357 <p id="rfc.section. 7.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section 4.2</a> for further discussion of the freshness model.1358 </p> 1359 <p id="rfc.section. 7.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after1399 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2> 1400 <p id="rfc.section.5.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section 4.2</a> for further discussion of the freshness model. 1401 </p> 1402 <p id="rfc.section.5.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after 1360 1403 that time. 1361 1404 </p> 1362 <p id="rfc.section. 7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.1405 <p id="rfc.section.5.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. 1363 1406 </p> 1364 1407 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a> 1365 1408 </pre><div id="rfc.figure.u.10"></div> 1366 1409 <p>For example</p><pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1367 </pre><p id="rfc.section. 7.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").1368 </p> 1369 <p id="rfc.section. 7.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.8</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.9</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented1410 </pre><p id="rfc.section.5.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired"). 1411 </p> 1412 <p id="rfc.section.5.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section 5.2.2.8</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 5.2.2.9</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented 1370 1413 the Cache-Control field. 1371 1414 </p> 1372 <p id="rfc.section. 7.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated1415 <p id="rfc.section.5.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated 1373 1416 with the resource by a system or user with a reliable clock. 1374 1417 </p> 1375 <p id="rfc.section. 7.3.p.9">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes1418 <p id="rfc.section.5.3.p.9">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes 1376 1419 are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use 1377 1420 of 32-bit integers for time values), and many caches will evict a response far sooner than that. 1378 1421 </p> 1379 1422 <div id="rfc.iref.p.5"></div> 1380 <h2 id="rfc.section. 7.4"><a href="#rfc.section.7.4">7.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2>1381 <p id="rfc.section. 7.4.p.1">The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request1423 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> 1424 <p id="rfc.section.5.4.p.1">The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request 1382 1425 that they will understand (as <a href="#header.cache-control" class="smpl">Cache-Control</a> was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is 1383 1426 ignored. 1384 1427 </p> 1385 <p id="rfc.section. 7.4.p.2">In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification1428 <p id="rfc.section.5.4.p.2">In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification 1386 1429 deprecates such extensions to improve interoperability. 1387 1430 </p> … … 1389 1432 <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a> 1390 1433 <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ] 1391 </pre><p id="rfc.section. 7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>).1392 </p> 1393 <p id="rfc.section. 7.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:1434 </pre><p id="rfc.section.5.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 5.2.1</a>). 1435 </p> 1436 <p id="rfc.section.5.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: 1394 1437 no-cache is purposefully omitted to target other <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives at HTTP/1.1 caches. For example: 1395 1438 </p> … … 1399 1442 Pragma: no-cache 1400 1443 1401 </pre><p id="rfc.section. 7.4.p.7">will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not1444 </pre><p id="rfc.section.5.4.p.7">will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not 1402 1445 understand <a href="#header.cache-control" class="smpl">Cache-Control</a> from serving a cached response. 1403 1446 </p> 1404 <div class="note" id="rfc.section. 7.4.p.8">1447 <div class="note" id="rfc.section.5.4.p.8"> 1405 1448 <p><b>Note:</b> Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: 1406 1449 no-cache" in them. … … 1408 1451 </div> 1409 1452 <div id="rfc.iref.w.1"></div> 1410 <h2 id="rfc.section. 7.5"><a href="#rfc.section.7.5">7.5</a> <a id="header.warning" href="#header.warning">Warning</a></h2>1411 <p id="rfc.section. 7.5.p.1">The "Warning" header field is used to carry additional information about the status or transformation of a message that might1453 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="header.warning" href="#header.warning">Warning</a></h2> 1454 <p id="rfc.section.5.5.p.1">The "Warning" header field is used to carry additional information about the status or transformation of a message that might 1412 1455 not be reflected in the message. This information is typically used to warn about possible incorrectness introduced by caching 1413 1456 operations or transformations applied to the payload of the message. 1414 1457 </p> 1415 <p id="rfc.section. 7.5.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status1458 <p id="rfc.section.5.5.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status 1416 1459 code, distinguishes these responses from true failures. 1417 1460 </p> 1418 <p id="rfc.section. 7.5.p.3">Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only1461 <p id="rfc.section.5.5.p.3">Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only 1419 1462 be applied to response messages. 1420 1463 </p> … … 1430 1473 <a href="#header.warning" class="smpl">warn-text</a> = <a href="#imported.abnf" class="smpl">quoted-string</a> 1431 1474 <a href="#header.warning" class="smpl">warn-date</a> = <a href="#imported.abnf" class="smpl">DQUOTE</a> <a href="#imported.abnf" class="smpl">HTTP-date</a> <a href="#imported.abnf" class="smpl">DQUOTE</a> 1432 </pre><p id="rfc.section. 7.5.p.5">Multiple warnings can be attached to a response (either by the origin server or by a cache), including multiple warnings with1475 </pre><p id="rfc.section.5.5.p.5">Multiple warnings can be attached to a response (either by the origin server or by a cache), including multiple warnings with 1433 1476 the same code number, only differing in warn-text. 1434 1477 </p> 1435 <p id="rfc.section. 7.5.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response.1436 </p> 1437 <p id="rfc.section. 7.5.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New1478 <p id="rfc.section.5.5.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response. 1479 </p> 1480 <p id="rfc.section.5.5.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New 1438 1481 Warning header fields are added after any existing Warning header fields. 1439 1482 </p> 1440 <p id="rfc.section. 7.5.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from1483 <p id="rfc.section.5.5.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from 1441 1484 a stored response after validation: 1442 1485 </p> … … 1448 1491 </li> 1449 1492 </ul> 1450 <p id="rfc.section. 7.5.p.9">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Thus, Warnings in responses1493 <p id="rfc.section.5.5.p.9">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Thus, Warnings in responses 1451 1494 carry a warning-date field, which can help in detecting an erroneously cached Warning. 1452 1495 </p> 1453 <p id="rfc.section. 7.5.p.10">RFC 2616 made the Warning header field's warn-date component optional; it was only required to be sent when the recipient's1496 <p id="rfc.section.5.5.p.10">RFC 2616 made the Warning header field's warn-date component optional; it was only required to be sent when the recipient's 1454 1497 version was HTTP/1.0 or lower. However, deployment experience has shown that many intermediaries do not process the Warning 1455 1498 header field as required by RFC 2616. This results in situations where the field can appear in messages where it is not applicable, 1456 1499 because a warning-value has not been removed by an intermediary. 1457 1500 </p> 1458 <p id="rfc.section. 7.5.p.11">As a result, this specification shifts responsibility for processing of Warning from intermediaries to the recipient that1501 <p id="rfc.section.5.5.p.11">As a result, this specification shifts responsibility for processing of Warning from intermediaries to the recipient that 1459 1502 is actually consuming them. 1460 1503 </p> 1461 <p id="rfc.section. 7.5.p.12">Generators of Warning header fields <em class="bcp14">MUST</em> include in every warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message. Recipients that process a Warning header field <em class="bcp14">MUST</em> ignore (and <em class="bcp14">MAY</em> remove before forwarding) a warning-value whose warn-date is different from the Date value in the response.1462 </p> 1463 <p id="rfc.section. 7.5.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description1504 <p id="rfc.section.5.5.p.12">Generators of Warning header fields <em class="bcp14">MUST</em> include in every warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message. Recipients that process a Warning header field <em class="bcp14">MUST</em> ignore (and <em class="bcp14">MAY</em> remove before forwarding) a warning-value whose warn-date is different from the Date value in the response. 1505 </p> 1506 <p id="rfc.section.5.5.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description 1464 1507 of its meaning. 1465 1508 </p> 1466 1509 <div id="rfc.iref.50"></div> 1467 <h3 id="rfc.section. 7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a> <a id="warn.110" href="#warn.110">110 Response is Stale</a></h3>1468 <p id="rfc.section. 7.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale.1510 <h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a> <a id="warn.110" href="#warn.110">110 Response is Stale</a></h3> 1511 <p id="rfc.section.5.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale. 1469 1512 </p> 1470 1513 <div id="rfc.iref.50"></div> 1471 <h3 id="rfc.section. 7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a> <a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3>1472 <p id="rfc.section. 7.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach1514 <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a> <a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3> 1515 <p id="rfc.section.5.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach 1473 1516 the server. 1474 1517 </p> 1475 1518 <div id="rfc.iref.50"></div> 1476 <h3 id="rfc.section. 7.5.3"><a href="#rfc.section.7.5.3">7.5.3</a> <a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3>1477 <p id="rfc.section. 7.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time.1519 <h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a> <a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3> 1520 <p id="rfc.section.5.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time. 1478 1521 </p> 1479 1522 <div id="rfc.iref.50"></div> 1480 <h3 id="rfc.section. 7.5.4"><a href="#rfc.section.7.5.4">7.5.4</a> <a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3>1481 <p id="rfc.section. 7.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than1523 <h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a> <a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3> 1524 <p id="rfc.section.5.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 1482 1525 24 hours. 1483 1526 </p> 1484 1527 <div id="rfc.iref.50"></div> 1485 <h3 id="rfc.section. 7.5.5"><a href="#rfc.section.7.5.5">7.5.5</a> <a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3>1486 <p id="rfc.section. 7.5.5.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.1528 <h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a> <a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3> 1529 <p id="rfc.section.5.5.5.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user. 1487 1530 </p> 1488 1531 <div id="rfc.iref.50"></div> 1489 <h3 id="rfc.section. 7.5.6"><a href="#rfc.section.7.5.6">7.5.6</a> <a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3>1490 <p id="rfc.section. 7.5.6.p.1"><em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type,1532 <h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a> <a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3> 1533 <p id="rfc.section.5.5.6.p.1"><em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, 1491 1534 or modifying the representation data, unless this Warning code already appears in the response. 1492 1535 </p> 1493 1536 <div id="rfc.iref.50"></div> 1494 <h3 id="rfc.section. 7.5.7"><a href="#rfc.section.7.5.7">7.5.7</a> <a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3>1495 <p id="rfc.section. 7.5.7.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.1496 </p> 1497 <h3 id="rfc.section. 7.5.8"><a href="#rfc.section.7.5.8">7.5.8</a> <a id="warn.code.extensions" href="#warn.code.extensions">Warn Code Extensions</a></h3>1498 <p id="rfc.section. 7.5.8.p.1">Extension warn codes can be defined; see <a href="#warn.code.registry.procedure" title="Procedure">Section 9.2.1</a> for details.1499 </p> 1500 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> <a id="history.lists" href="#history.lists">History Lists</a></h1>1501 <p id="rfc.section. 8.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation1537 <h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a> <a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3> 1538 <p id="rfc.section.5.5.7.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action. 1539 </p> 1540 <h3 id="rfc.section.5.5.8"><a href="#rfc.section.5.5.8">5.5.8</a> <a id="warn.code.extensions" href="#warn.code.extensions">Warn Code Extensions</a></h3> 1541 <p id="rfc.section.5.5.8.p.1">Extension warn codes can be defined; see <a href="#warn.code.registry.procedure" title="Procedure">Section 7.2.1</a> for details. 1542 </p> 1543 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="history.lists" href="#history.lists">History Lists</a></h1> 1544 <p id="rfc.section.6.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation 1502 1545 retrieved earlier in a session. 1503 1546 </p> 1504 <p id="rfc.section. 8.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section 4.2</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if1547 <p id="rfc.section.6.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section 4.2</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if 1505 1548 it has expired. 1506 1549 </p> 1507 <p id="rfc.section. 8.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives1550 <p id="rfc.section.6.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives 1508 1551 (e.g., Cache-Control: no-store). 1509 1552 </p> 1510 <h1 id="rfc.section. 9"><a href="#rfc.section.9">9.</a> <a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>1511 <h2 id="rfc.section. 9.1"><a href="#rfc.section.9.1">9.1</a> <a id="cache.directive.registry" href="#cache.directive.registry">Cache Directive Registry</a></h2>1512 <p id="rfc.section. 9.1.p.1">The HTTP Cache Directive Registry defines the name space for the cache directives. It will be created and maintained at <<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>>.1513 </p> 1514 <h3 id="rfc.section. 9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a> <a id="cache.directive.registry.procedure" href="#cache.directive.registry.procedure">Procedure</a></h3>1515 <p id="rfc.section. 9.1.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields:1553 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1> 1554 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="cache.directive.registry" href="#cache.directive.registry">Cache Directive Registry</a></h2> 1555 <p id="rfc.section.7.1.p.1">The HTTP Cache Directive Registry defines the name space for the cache directives. It will be created and maintained at <<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>>. 1556 </p> 1557 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="cache.directive.registry.procedure" href="#cache.directive.registry.procedure">Procedure</a></h3> 1558 <p id="rfc.section.7.1.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: 1516 1559 </p> 1517 1560 <ul> … … 1519 1562 <li>Pointer to specification text</li> 1520 1563 </ul> 1521 <p id="rfc.section. 9.1.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).1522 </p> 1523 <h3 id="rfc.section. 9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a> <a id="cache.directive.considerations" href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3>1524 <p id="rfc.section. 9.1.2.p.1">New extension directives ought to consider defining:</p>1525 <p id="rfc.section. 9.1.2.p.2"></p>1564 <p id="rfc.section.7.1.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 1565 </p> 1566 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="cache.directive.considerations" href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3> 1567 <p id="rfc.section.7.1.2.p.1">New extension directives ought to consider defining:</p> 1568 <p id="rfc.section.7.1.2.p.2"></p> 1526 1569 <ul> 1527 1570 <li>What it means for a directive to be specified multiple times,</li> … … 1530 1573 <li>Whether the directive is specific to requests, responses, or able to be used in either.</li> 1531 1574 </ul> 1532 <p id="rfc.section. 9.1.2.p.3">See also <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a>.1533 </p> 1534 <h3 id="rfc.section. 9.1.3"><a href="#rfc.section.9.1.3">9.1.3</a> <a id="cache.directive.registration" href="#cache.directive.registration">Registrations</a></h3>1535 <p id="rfc.section. 9.1.3.p.1">The HTTP Cache Directive Registry shall be populated with the registrations below:</p>1575 <p id="rfc.section.7.1.2.p.3">See also <a href="#cache.control.extensions" title="Cache Control Extensions">Section 5.2.3</a>. 1576 </p> 1577 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="cache.directive.registration" href="#cache.directive.registration">Registrations</a></h3> 1578 <p id="rfc.section.7.1.3.p.1">The HTTP Cache Directive Registry shall be populated with the registrations below:</p> 1536 1579 <div id="rfc.table.1"> 1537 1580 <div id="iana.cache.directive.registration.table"></div> … … 1546 1589 <tr> 1547 1590 <td class="left">max-age</td> 1548 <td class="left"><a href="#cache-request-directive.max-age" title="max-age">Section 7.2.1.1</a>, <a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.8</a>1591 <td class="left"><a href="#cache-request-directive.max-age" title="max-age">Section 5.2.1.1</a>, <a href="#cache-response-directive.max-age" title="max-age">Section 5.2.2.8</a> 1549 1592 </td> 1550 1593 </tr> 1551 1594 <tr> 1552 1595 <td class="left">max-stale</td> 1553 <td class="left"><a href="#cache-request-directive.max-stale" title="max-stale">Section 7.2.1.2</a>1596 <td class="left"><a href="#cache-request-directive.max-stale" title="max-stale">Section 5.2.1.2</a> 1554 1597 </td> 1555 1598 </tr> 1556 1599 <tr> 1557 1600 <td class="left">min-fresh</td> 1558 <td class="left"><a href="#cache-request-directive.min-fresh" title="min-fresh">Section 7.2.1.3</a>1601 <td class="left"><a href="#cache-request-directive.min-fresh" title="min-fresh">Section 5.2.1.3</a> 1559 1602 </td> 1560 1603 </tr> 1561 1604 <tr> 1562 1605 <td class="left">must-revalidate</td> 1563 <td class="left"><a href="#cache-response-directive.must-revalidate" title="must-revalidate">Section 7.2.2.1</a>1606 <td class="left"><a href="#cache-response-directive.must-revalidate" title="must-revalidate">Section 5.2.2.1</a> 1564 1607 </td> 1565 1608 </tr> 1566 1609 <tr> 1567 1610 <td class="left">no-cache</td> 1568 <td class="left"><a href="#cache-request-directive.no-cache" title="no-cache">Section 7.2.1.4</a>, <a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>1611 <td class="left"><a href="#cache-request-directive.no-cache" title="no-cache">Section 5.2.1.4</a>, <a href="#cache-response-directive.no-cache" title="no-cache">Section 5.2.2.2</a> 1569 1612 </td> 1570 1613 </tr> 1571 1614 <tr> 1572 1615 <td class="left">no-store</td> 1573 <td class="left"><a href="#cache-request-directive.no-store" title="no-store">Section 7.2.1.5</a>, <a href="#cache-response-directive.no-store" title="no-store">Section 7.2.2.3</a>1616 <td class="left"><a href="#cache-request-directive.no-store" title="no-store">Section 5.2.1.5</a>, <a href="#cache-response-directive.no-store" title="no-store">Section 5.2.2.3</a> 1574 1617 </td> 1575 1618 </tr> 1576 1619 <tr> 1577 1620 <td class="left">no-transform</td> 1578 <td class="left"><a href="#cache-request-directive.no-transform" title="no-transform">Section 7.2.1.6</a>, <a href="#cache-response-directive.no-transform" title="no-transform">Section 7.2.2.4</a>1621 <td class="left"><a href="#cache-request-directive.no-transform" title="no-transform">Section 5.2.1.6</a>, <a href="#cache-response-directive.no-transform" title="no-transform">Section 5.2.2.4</a> 1579 1622 </td> 1580 1623 </tr> 1581 1624 <tr> 1582 1625 <td class="left">only-if-cached</td> 1583 <td class="left"><a href="#cache-request-directive.only-if-cached" title="only-if-cached">Section 7.2.1.7</a>1626 <td class="left"><a href="#cache-request-directive.only-if-cached" title="only-if-cached">Section 5.2.1.7</a> 1584 1627 </td> 1585 1628 </tr> 1586 1629 <tr> 1587 1630 <td class="left">private</td> 1588 <td class="left"><a href="#cache-response-directive.private" title="private">Section 7.2.2.6</a>1631 <td class="left"><a href="#cache-response-directive.private" title="private">Section 5.2.2.6</a> 1589 1632 </td> 1590 1633 </tr> 1591 1634 <tr> 1592 1635 <td class="left">proxy-revalidate</td> 1593 <td class="left"><a href="#cache-response-directive.proxy-revalidate" title="proxy-revalidate">Section 7.2.2.7</a>1636 <td class="left"><a href="#cache-response-directive.proxy-revalidate" title="proxy-revalidate">Section 5.2.2.7</a> 1594 1637 </td> 1595 1638 </tr> 1596 1639 <tr> 1597 1640 <td class="left">public</td> 1598 <td class="left"><a href="#cache-response-directive.public" title="public">Section 7.2.2.5</a>1641 <td class="left"><a href="#cache-response-directive.public" title="public">Section 5.2.2.5</a> 1599 1642 </td> 1600 1643 </tr> 1601 1644 <tr> 1602 1645 <td class="left">s-maxage</td> 1603 <td class="left"><a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.9</a>1646 <td class="left"><a href="#cache-response-directive.s-maxage" title="s-maxage">Section 5.2.2.9</a> 1604 1647 </td> 1605 1648 </tr> … … 1617 1660 </table> 1618 1661 </div> 1619 <h2 id="rfc.section. 9.2"><a href="#rfc.section.9.2">9.2</a> <a id="warn.code.registry" href="#warn.code.registry">Warn Code Registry</a></h2>1620 <p id="rfc.section. 9.2.p.1">The HTTP Warn Code Registry defines the name space for warn codes. It will be created and maintained at <<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>>.1621 </p> 1622 <h3 id="rfc.section. 9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a> <a id="warn.code.registry.procedure" href="#warn.code.registry.procedure">Procedure</a></h3>1623 <p id="rfc.section. 9.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields:1662 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="warn.code.registry" href="#warn.code.registry">Warn Code Registry</a></h2> 1663 <p id="rfc.section.7.2.p.1">The HTTP Warn Code Registry defines the name space for warn codes. It will be created and maintained at <<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>>. 1664 </p> 1665 <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="warn.code.registry.procedure" href="#warn.code.registry.procedure">Procedure</a></h3> 1666 <p id="rfc.section.7.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: 1624 1667 </p> 1625 1668 <ul> … … 1628 1671 <li>Pointer to specification text</li> 1629 1672 </ul> 1630 <p id="rfc.section. 9.2.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).1631 </p> 1632 <h3 id="rfc.section. 9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a> <a id="warn.code.registration" href="#warn.code.registration">Registrations</a></h3>1633 <p id="rfc.section. 9.2.2.p.1">The HTTP Warn Code Registry shall be populated with the registrations below:</p>1673 <p id="rfc.section.7.2.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 1674 </p> 1675 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="warn.code.registration" href="#warn.code.registration">Registrations</a></h3> 1676 <p id="rfc.section.7.2.2.p.1">The HTTP Warn Code Registry shall be populated with the registrations below:</p> 1634 1677 <div id="rfc.table.2"> 1635 1678 <div id="iana.warn.code.registration.table"></div> … … 1646 1689 <td class="left">110</td> 1647 1690 <td class="left">Response is Stale</td> 1648 <td class="left"><a href="#warn.110" id="rfc.xref.warn.110.1" title="110 Response is Stale">Section 7.5.1</a>1691 <td class="left"><a href="#warn.110" id="rfc.xref.warn.110.1" title="110 Response is Stale">Section 5.5.1</a> 1649 1692 </td> 1650 1693 </tr> … … 1652 1695 <td class="left">111</td> 1653 1696 <td class="left">Revalidation Failed</td> 1654 <td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="111 Revalidation Failed">Section 7.5.2</a>1697 <td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="111 Revalidation Failed">Section 5.5.2</a> 1655 1698 </td> 1656 1699 </tr> … … 1658 1701 <td class="left">112</td> 1659 1702 <td class="left">Disconnected Operation</td> 1660 <td class="left"><a href="#warn.112" id="rfc.xref.warn.112.1" title="112 Disconnected Operation">Section 7.5.3</a>1703 <td class="left"><a href="#warn.112" id="rfc.xref.warn.112.1" title="112 Disconnected Operation">Section 5.5.3</a> 1661 1704 </td> 1662 1705 </tr> … … 1664 1707 <td class="left">113</td> 1665 1708 <td class="left">Heuristic Expiration</td> 1666 <td class="left"><a href="#warn.113" id="rfc.xref.warn.113.1" title="113 Heuristic Expiration">Section 7.5.4</a>1709 <td class="left"><a href="#warn.113" id="rfc.xref.warn.113.1" title="113 Heuristic Expiration">Section 5.5.4</a> 1667 1710 </td> 1668 1711 </tr> … … 1670 1713 <td class="left">199</td> 1671 1714 <td class="left">Miscellaneous Warning</td> 1672 <td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="199 Miscellaneous Warning">Section 7.5.5</a>1715 <td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="199 Miscellaneous Warning">Section 5.5.5</a> 1673 1716 </td> 1674 1717 </tr> … … 1676 1719 <td class="left">214</td> 1677 1720 <td class="left">Transformation Applied</td> 1678 <td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="214 Transformation Applied">Section 7.5.6</a>1721 <td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="214 Transformation Applied">Section 5.5.6</a> 1679 1722 </td> 1680 1723 </tr> … … 1682 1725 <td class="left">299</td> 1683 1726 <td class="left">Miscellaneous Persistent Warning</td> 1684 <td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="299 Miscellaneous Persistent Warning">Section 7.5.7</a>1727 <td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="299 Miscellaneous Persistent Warning">Section 5.5.7</a> 1685 1728 </td> 1686 1729 </tr> … … 1688 1731 </table> 1689 1732 </div> 1690 <h2 id="rfc.section. 9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>1691 <p id="rfc.section. 9.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>.1692 </p> 1693 <p id="rfc.section. 9.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to1733 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1734 <p id="rfc.section.7.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>. 1735 </p> 1736 <p id="rfc.section.7.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to 1694 1737 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1695 1738 </p> … … 1710 1753 <td class="left">http</td> 1711 1754 <td class="left">standard</td> 1712 <td class="left"><a href="#header.age" id="rfc.xref.header.age.3" title="Age">Section 7.1</a>1755 <td class="left"><a href="#header.age" id="rfc.xref.header.age.3" title="Age">Section 5.1</a> 1713 1756 </td> 1714 1757 </tr> … … 1717 1760 <td class="left">http</td> 1718 1761 <td class="left">standard</td> 1719 <td class="left"><a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 7.2</a>1762 <td class="left"><a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 5.2</a> 1720 1763 </td> 1721 1764 </tr> … … 1724 1767 <td class="left">http</td> 1725 1768 <td class="left">standard</td> 1726 <td class="left"><a href="#header.expires" id="rfc.xref.header.expires.4" title="Expires">Section 7.3</a>1769 <td class="left"><a href="#header.expires" id="rfc.xref.header.expires.4" title="Expires">Section 5.3</a> 1727 1770 </td> 1728 1771 </tr> … … 1731 1774 <td class="left">http</td> 1732 1775 <td class="left">standard</td> 1733 <td class="left"><a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 7.4</a>1776 <td class="left"><a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 5.4</a> 1734 1777 </td> 1735 1778 </tr> … … 1738 1781 <td class="left">http</td> 1739 1782 <td class="left">standard</td> 1740 <td class="left"><a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 7.5</a>1783 <td class="left"><a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 5.5</a> 1741 1784 </td> 1742 1785 </tr> … … 1744 1787 </table> 1745 1788 </div> 1746 <p id="rfc.section. 9.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1747 <h1 id="rfc.section. 10"><a href="#rfc.section.10">10.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1748 <p id="rfc.section. 10.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.11789 <p id="rfc.section.7.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1790 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1791 <p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1 1749 1792 caching. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. 1750 1793 </p> 1751 <p id="rfc.section. 10.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious1794 <p id="rfc.section.8.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious 1752 1795 exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information 1753 1796 long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected 1754 1797 as sensitive information. 1755 1798 </p> 1756 <p id="rfc.section. 10.p.3">Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first1799 <p id="rfc.section.8.p.3">Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first 1757 1800 one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it 1758 1801 load more quickly, thanks to the cache. 1759 1802 </p> 1760 <p id="rfc.section. 10.p.4">Implementation flaws might allow attackers to insert content into a cache ("cache poisoning"), leading to compromise of clients1803 <p id="rfc.section.8.p.4">Implementation flaws might allow attackers to insert content into a cache ("cache poisoning"), leading to compromise of clients 1761 1804 that trust that content. Because of their nature, these attacks are difficult to mitigate. 1762 1805 </p> 1763 <p id="rfc.section. 10.p.5">Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information1806 <p id="rfc.section.8.p.5">Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information 1764 1807 (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties. 1765 1808 </p> 1766 <p id="rfc.section. 10.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent1809 <p id="rfc.section.8.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent 1767 1810 requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control 1768 1811 response header fields. 1769 1812 </p> 1770 <h1 id="rfc.section. 11"><a href="#rfc.section.11">11.</a> <a id="acks" href="#acks">Acknowledgments</a></h1>1771 <p id="rfc.section. 11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.1772 </p> 1773 <h1 id="rfc.references"><a id="rfc.section.1 2" href="#rfc.section.12">12.</a> References1813 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1814 <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 1815 </p> 1816 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References 1774 1817 </h1> 1775 <h2 id="rfc.references.1"><a href="#rfc.section.1 2.1" id="rfc.section.12.1">12.1</a> Normative References1818 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 1776 1819 </h2> 1777 1820 <table> … … 1812 1855 </tr> 1813 1856 </table> 1814 <h2 id="rfc.references.2"><a href="#rfc.section.1 2.2" id="rfc.section.12.2">12.2</a> Informative References1857 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 1815 1858 </h2> 1816 1859 <table> … … 1873 1916 explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) 1874 1917 </p> 1875 <p id="rfc.section.A.p.7">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation .after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>)1876 </p> 1877 <p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation .after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>)1918 <p id="rfc.section.A.p.7">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation" title="Invalidation">Section 4.4</a>) 1919 </p> 1920 <p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation" title="Invalidation">Section 4.4</a>) 1878 1921 </p> 1879 1922 <p id="rfc.section.A.p.9">Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only 1880 one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 7.2</a>)1923 one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 5.2</a>) 1881 1924 </p> 1882 1925 <p id="rfc.section.A.p.10">The "no-store" cache request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it, 1883 and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section 7.2.1.5</a>)1926 and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section 5.2.1.5</a>) 1884 1927 </p> 1885 1928 <p id="rfc.section.A.p.11">The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; e.g., "private=foo" 1886 1929 is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. 1887 (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>)1888 </p> 1889 <p id="rfc.section.A.p.12">The "no-cache" response cache directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>)1890 </p> 1891 <p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section 7.3</a>)1892 </p> 1893 <p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section 7.4</a>)1930 (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 5.2.2</a>) 1931 </p> 1932 <p id="rfc.section.A.p.12">The "no-cache" response cache directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section 5.2.2.2</a>) 1933 </p> 1934 <p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section 5.3</a>) 1935 </p> 1936 <p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section 5.4</a>) 1894 1937 </p> 1895 1938 <p id="rfc.section.A.p.15">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, presence of the warn-date component has been 1896 made required (dropping requirements specific to HTTP/1.0). Finally, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section 7.5</a>)1939 made required (dropping requirements specific to HTTP/1.0). Finally, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section 5.5</a>) 1897 1940 </p> 1898 1941 <p id="rfc.section.A.p.16">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. 1899 (<a href="#cache.directive.registry" title="Cache Directive Registry">Section 9.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section 9.2</a>)1942 (<a href="#cache.directive.registry" title="Cache Directive Registry">Section 7.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section 7.2</a>) 1900 1943 </p> 1901 1944 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 2032 2075 <ul class="ind"> 2033 2076 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 2034 <li>110 Response is Stale (warn code) <a href="#rfc.iref.50"><b> 7.5.1</b></a>, <a href="#rfc.xref.warn.110.1">9.2.2</a></li>2035 <li>111 Revalidation Failed (warn code) <a href="#rfc.iref.50"><b> 7.5.2</b></a>, <a href="#rfc.xref.warn.111.1">9.2.2</a></li>2036 <li>112 Disconnected Operation (warn code) <a href="#rfc.iref.50"><b> 7.5.3</b></a>, <a href="#rfc.xref.warn.112.1">9.2.2</a></li>2037 <li>113 Heuristic Expiration (warn code) <a href="#rfc.iref.50"><b> 7.5.4</b></a>, <a href="#rfc.xref.warn.113.1">9.2.2</a></li>2038 <li>199 Miscellaneous Warning (warn code) <a href="#rfc.iref.50"><b> 7.5.5</b></a>, <a href="#rfc.xref.warn.199.1">9.2.2</a></li>2077 <li>110 Response is Stale (warn code) <a href="#rfc.iref.50"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.1">7.2.2</a></li> 2078 <li>111 Revalidation Failed (warn code) <a href="#rfc.iref.50"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li> 2079 <li>112 Disconnected Operation (warn code) <a href="#rfc.iref.50"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.1">7.2.2</a></li> 2080 <li>113 Heuristic Expiration (warn code) <a href="#rfc.iref.50"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.1">7.2.2</a></li> 2081 <li>199 Miscellaneous Warning (warn code) <a href="#rfc.iref.50"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li> 2039 2082 </ul> 2040 2083 </li> 2041 2084 <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> 2042 <li>214 Transformation Applied (warn code) <a href="#rfc.iref.50"><b> 7.5.6</b></a>, <a href="#rfc.xref.warn.214.1">9.2.2</a></li>2043 <li>299 Miscellaneous Persistent Warning (warn code) <a href="#rfc.iref.50"><b> 7.5.7</b></a>, <a href="#rfc.xref.warn.299.1">9.2.2</a></li>2085 <li>214 Transformation Applied (warn code) <a href="#rfc.iref.50"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li> 2086 <li>299 Miscellaneous Persistent Warning (warn code) <a href="#rfc.iref.50"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li> 2044 2087 </ul> 2045 2088 </li> 2046 2089 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 2047 2090 <li>age <a href="#rfc.iref.a.1">4.2</a></li> 2048 <li>Age header field <a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b> 7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li>2091 <li>Age header field <a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>5.1</b></a>, <a href="#rfc.xref.header.age.3">7.3</a></li> 2049 2092 </ul> 2050 2093 </li> 2051 2094 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 2052 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1"> 9.3</a>, <a href="#BCP90"><b>12.2</b></a></li>2095 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">7.3</a>, <a href="#BCP90"><b>10.2</b></a></li> 2053 2096 </ul> 2054 2097 </li> … … 2057 2100 <li>cache entry <a href="#rfc.iref.c.2">2</a></li> 2058 2101 <li>cache key <a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li> 2059 <li>Cache-Control header field <a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b> 7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li>2102 <li>Cache-Control header field <a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>5.2</b></a>, <a href="#rfc.xref.header.cache-control.2">7.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li> 2060 2103 </ul> 2061 2104 </li> 2062 2105 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 2063 <li>Expires header field <a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b> 7.3</b></a>, <a href="#rfc.xref.header.expires.4">9.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li>2106 <li>Expires header field <a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>5.3</b></a>, <a href="#rfc.xref.header.expires.4">7.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li> 2064 2107 <li>explicit expiration time <a href="#rfc.iref.e.1">4.2</a></li> 2065 2108 </ul> … … 2074 2117 <li><tt>Grammar</tt> 2075 2118 <ul> 2076 <li><tt>Age</tt> <a href="#rfc.iref.g.2"><b> 7.1</b></a></li>2077 <li><tt>Cache-Control</tt> <a href="#rfc.iref.g.3"><b> 7.2</b></a></li>2078 <li><tt>cache-directive</tt> <a href="#rfc.iref.g.4"><b> 7.2</b></a></li>2119 <li><tt>Age</tt> <a href="#rfc.iref.g.2"><b>5.1</b></a></li> 2120 <li><tt>Cache-Control</tt> <a href="#rfc.iref.g.3"><b>5.2</b></a></li> 2121 <li><tt>cache-directive</tt> <a href="#rfc.iref.g.4"><b>5.2</b></a></li> 2079 2122 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.1"><b>1.2.1</b></a></li> 2080 <li><tt>Expires</tt> <a href="#rfc.iref.g.5"><b> 7.3</b></a></li>2081 <li><tt>extension-pragma</tt> <a href="#rfc.iref.g.8"><b> 7.4</b></a></li>2082 <li><tt>Pragma</tt> <a href="#rfc.iref.g.6"><b> 7.4</b></a></li>2083 <li><tt>pragma-directive</tt> <a href="#rfc.iref.g.7"><b> 7.4</b></a></li>2084 <li><tt>warn-agent</tt> <a href="#rfc.iref.g.12"><b> 7.5</b></a></li>2085 <li><tt>warn-code</tt> <a href="#rfc.iref.g.11"><b> 7.5</b></a></li>2086 <li><tt>warn-date</tt> <a href="#rfc.iref.g.14"><b> 7.5</b></a></li>2087 <li><tt>warn-text</tt> <a href="#rfc.iref.g.13"><b> 7.5</b></a></li>2088 <li><tt>Warning</tt> <a href="#rfc.iref.g.9"><b> 7.5</b></a></li>2089 <li><tt>warning-value</tt> <a href="#rfc.iref.g.10"><b> 7.5</b></a></li>2123 <li><tt>Expires</tt> <a href="#rfc.iref.g.5"><b>5.3</b></a></li> 2124 <li><tt>extension-pragma</tt> <a href="#rfc.iref.g.8"><b>5.4</b></a></li> 2125 <li><tt>Pragma</tt> <a href="#rfc.iref.g.6"><b>5.4</b></a></li> 2126 <li><tt>pragma-directive</tt> <a href="#rfc.iref.g.7"><b>5.4</b></a></li> 2127 <li><tt>warn-agent</tt> <a href="#rfc.iref.g.12"><b>5.5</b></a></li> 2128 <li><tt>warn-code</tt> <a href="#rfc.iref.g.11"><b>5.5</b></a></li> 2129 <li><tt>warn-date</tt> <a href="#rfc.iref.g.14"><b>5.5</b></a></li> 2130 <li><tt>warn-text</tt> <a href="#rfc.iref.g.13"><b>5.5</b></a></li> 2131 <li><tt>Warning</tt> <a href="#rfc.iref.g.9"><b>5.5</b></a></li> 2132 <li><tt>warning-value</tt> <a href="#rfc.iref.g.10"><b>5.5</b></a></li> 2090 2133 </ul> 2091 2134 </li> … … 2097 2140 </li> 2098 2141 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 2099 <li>max-age (cache directive) <a href="#rfc.iref.m.1"><b> 7.2.1.1</b></a>, <a href="#rfc.iref.m.5"><b>7.2.2.8</b></a></li>2100 <li>max-stale (cache directive) <a href="#rfc.iref.m.2"><b> 7.2.1.2</b></a></li>2101 <li>min-fresh (cache directive) <a href="#rfc.iref.m.3"><b> 7.2.1.3</b></a></li>2102 <li>must-revalidate (cache directive) <a href="#rfc.iref.m.4"><b> 7.2.2.1</b></a></li>2142 <li>max-age (cache directive) <a href="#rfc.iref.m.1"><b>5.2.1.1</b></a>, <a href="#rfc.iref.m.5"><b>5.2.2.8</b></a></li> 2143 <li>max-stale (cache directive) <a href="#rfc.iref.m.2"><b>5.2.1.2</b></a></li> 2144 <li>min-fresh (cache directive) <a href="#rfc.iref.m.3"><b>5.2.1.3</b></a></li> 2145 <li>must-revalidate (cache directive) <a href="#rfc.iref.m.4"><b>5.2.2.1</b></a></li> 2103 2146 </ul> 2104 2147 </li> 2105 2148 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 2106 <li>no-cache (cache directive) <a href="#rfc.iref.n.1"><b> 7.2.1.4</b></a>, <a href="#rfc.iref.n.4"><b>7.2.2.2</b></a></li>2107 <li>no-store (cache directive) <a href="#rfc.iref.n.2"><b> 7.2.1.5</b></a>, <a href="#rfc.iref.n.5"><b>7.2.2.3</b></a></li>2108 <li>no-transform (cache directive) <a href="#rfc.iref.n.3"><b> 7.2.1.6</b></a>, <a href="#rfc.iref.n.6"><b>7.2.2.4</b></a></li>2149 <li>no-cache (cache directive) <a href="#rfc.iref.n.1"><b>5.2.1.4</b></a>, <a href="#rfc.iref.n.4"><b>5.2.2.2</b></a></li> 2150 <li>no-store (cache directive) <a href="#rfc.iref.n.2"><b>5.2.1.5</b></a>, <a href="#rfc.iref.n.5"><b>5.2.2.3</b></a></li> 2151 <li>no-transform (cache directive) <a href="#rfc.iref.n.3"><b>5.2.1.6</b></a>, <a href="#rfc.iref.n.6"><b>5.2.2.4</b></a></li> 2109 2152 </ul> 2110 2153 </li> 2111 2154 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 2112 <li>only-if-cached (cache directive) <a href="#rfc.iref.o.1"><b> 7.2.1.7</b></a></li>2155 <li>only-if-cached (cache directive) <a href="#rfc.iref.o.1"><b>5.2.1.7</b></a></li> 2113 2156 </ul> 2114 2157 </li> 2115 2158 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2116 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.6"> 6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>2159 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.6">4.4</a>, <a href="#rfc.xref.Part1.7">4.4</a>, <a href="#rfc.xref.Part1.8">4.4</a>, <a href="#rfc.xref.Part1.9">5.2.1.6</a>, <a href="#rfc.xref.Part1.10">5.2.2.4</a>, <a href="#rfc.xref.Part1.11">8</a>, <a href="#rfc.xref.Part1.12">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul> 2117 2160 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.21">C</a></li> 2118 2161 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.1">1.1</a></li> … … 2121 2164 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.14">B</a></li> 2122 2165 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a></li> 2123 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.6"> 6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a></li>2166 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.6">4.4</a>, <a href="#rfc.xref.Part1.7">4.4</a>, <a href="#rfc.xref.Part1.8">4.4</a></li> 2124 2167 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.19">B</a></li> 2125 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.9"> 7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a></li>2168 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.9">5.2.1.6</a>, <a href="#rfc.xref.Part1.10">5.2.2.4</a></li> 2126 2169 <li><em>Section 7</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 2127 <li><em>Section 10</em> <a href="#rfc.xref.Part1.12"> 11</a></li>2170 <li><em>Section 10</em> <a href="#rfc.xref.Part1.12">9</a></li> 2128 2171 </ul> 2129 2172 </li> 2130 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6"> 6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>2131 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6"> 6</a></li>2173 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6">4.4</a>, <a href="#rfc.xref.Part2.7">5.3</a>, <a href="#rfc.xref.Part2.8">8</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul> 2174 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">4.4</a></li> 2132 2175 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.2">2</a></li> 2133 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.7"> 7.3</a>, <a href="#rfc.xref.Part2.9">B</a></li>2176 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.7">5.3</a>, <a href="#rfc.xref.Part2.9">B</a></li> 2134 2177 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.5">4.2.3</a></li> 2135 2178 <li><em>Section 7.1.4</em> <a href="#rfc.xref.Part2.4">4.1</a></li> 2136 2179 </ul> 2137 2180 </li> 2138 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#Part4"><b>12.1</b></a><ul> 2139 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.3">4.3.1</a></li> 2140 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">4.2.2</a></li> 2181 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">4.3.1</a>, <a href="#rfc.xref.Part4.5">4.3.2</a>, <a href="#rfc.xref.Part4.6">4.3.2</a>, <a href="#rfc.xref.Part4.7">4.3.2</a>, <a href="#rfc.xref.Part4.8">4.3.2</a>, <a href="#rfc.xref.Part4.9">4.3.2</a>, <a href="#rfc.xref.Part4.10">4.3.4</a>, <a href="#Part4"><b>10.1</b></a><ul> 2182 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.10">4.3.4</a></li> 2183 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.3">4.3.1</a></li> 2184 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">4.3.1</a></li> 2185 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.6">4.3.2</a></li> 2186 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.8">4.3.2</a></li> 2187 <li><em>Section 3.3</em> <a href="#rfc.xref.Part4.9">4.3.2</a></li> 2188 <li><em>Section 3.4</em> <a href="#rfc.xref.Part4.7">4.3.2</a></li> 2189 <li><em>Section 6</em> <a href="#rfc.xref.Part4.5">4.3.2</a></li> 2141 2190 </ul> 2142 2191 </li> 2143 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#Part5"><b>12.1</b></a><ul> 2192 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.3.2</a>, <a href="#rfc.xref.Part5.5">4.3.2</a>, <a href="#Part5"><b>10.1</b></a><ul> 2193 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.5">4.3.2</a></li> 2144 2194 <li><em>Section 4.3</em> <a href="#rfc.xref.Part5.3">3.3</a></li> 2145 2195 </ul> 2146 2196 </li> 2147 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#Part7"><b>1 2.1</b></a><ul>2197 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#Part7"><b>10.1</b></a><ul> 2148 2198 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">3</a>, <a href="#rfc.xref.Part7.2">3.2</a></li> 2149 2199 </ul> 2150 2200 </li> 2151 <li>Pragma header field <a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b> 7.4</b></a>, <a href="#rfc.xref.header.pragma.2">9.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li>2152 <li>private (cache directive) <a href="#rfc.iref.p.3"><b> 7.2.2.6</b></a></li>2201 <li>Pragma header field <a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>5.4</b></a>, <a href="#rfc.xref.header.pragma.2">7.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li> 2202 <li>private (cache directive) <a href="#rfc.iref.p.3"><b>5.2.2.6</b></a></li> 2153 2203 <li>private cache <a href="#rfc.iref.p.1">1</a></li> 2154 <li>proxy-revalidate (cache directive) <a href="#rfc.iref.p.4"><b> 7.2.2.7</b></a></li>2155 <li>public (cache directive) <a href="#rfc.iref.p.2"><b> 7.2.2.5</b></a></li>2204 <li>proxy-revalidate (cache directive) <a href="#rfc.iref.p.4"><b>5.2.2.7</b></a></li> 2205 <li>public (cache directive) <a href="#rfc.iref.p.2"><b>5.2.2.5</b></a></li> 2156 2206 </ul> 2157 2207 </li> 2158 2208 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 2159 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4.2.3</a>, <a href="#RFC1305"><b>1 2.2</b></a></li>2160 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>1 2.1</b></a></li>2161 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>1 2.2</b></a><ul>2209 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4.2.3</a>, <a href="#RFC1305"><b>10.2</b></a></li> 2210 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 2211 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>10.2</b></a><ul> 2162 2212 <li><em>Section 13.9</em> <a href="#rfc.xref.RFC2616.1">4.2.2</a></li> 2163 2213 </ul> 2164 2214 </li> 2165 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1"> 9.1.1</a>, <a href="#rfc.xref.RFC5226.2">9.2.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>2166 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1"> 9.1.1</a>, <a href="#rfc.xref.RFC5226.2">9.2.1</a></li>2215 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul> 2216 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a></li> 2167 2217 </ul> 2168 2218 </li> 2169 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>1 2.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>2219 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul> 2170 2220 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">B</a></li> 2171 2221 </ul> 2172 2222 </li> 2173 <li><em>RFC5861</em> <a href="#rfc.xref.RFC5861.1"> 9.1.3</a>, <a href="#rfc.xref.RFC5861.2">9.1.3</a>, <a href="#RFC5861"><b>12.2</b></a><ul>2174 <li><em>Section 3</em> <a href="#rfc.xref.RFC5861.2"> 9.1.3</a></li>2175 <li><em>Section 4</em> <a href="#rfc.xref.RFC5861.1"> 9.1.3</a></li>2223 <li><em>RFC5861</em> <a href="#rfc.xref.RFC5861.1">7.1.3</a>, <a href="#rfc.xref.RFC5861.2">7.1.3</a>, <a href="#RFC5861"><b>10.2</b></a><ul> 2224 <li><em>Section 3</em> <a href="#rfc.xref.RFC5861.2">7.1.3</a></li> 2225 <li><em>Section 4</em> <a href="#rfc.xref.RFC5861.1">7.1.3</a></li> 2176 2226 </ul> 2177 2227 </li> 2178 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1"> 10</a>, <a href="#RFC6265"><b>12.2</b></a></li>2228 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">8</a>, <a href="#RFC6265"><b>10.2</b></a></li> 2179 2229 </ul> 2180 2230 </li> 2181 2231 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 2182 <li>s-maxage (cache directive) <a href="#rfc.iref.s.4"><b> 7.2.2.9</b></a></li>2232 <li>s-maxage (cache directive) <a href="#rfc.iref.s.4"><b>5.2.2.9</b></a></li> 2183 2233 <li>shared cache <a href="#rfc.iref.s.1">1</a></li> 2184 2234 <li>stale <a href="#rfc.iref.s.2">4.2</a></li> 2185 <li>strong validator <a href="#rfc.iref.s.3">4.3. 1</a></li>2235 <li>strong validator <a href="#rfc.iref.s.3">4.3.4</a></li> 2186 2236 </ul> 2187 2237 </li> 2188 2238 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 2189 <li>validator <a href="#rfc.iref.v.1">4.3 </a></li>2239 <li>validator <a href="#rfc.iref.v.1">4.3.1</a></li> 2190 2240 </ul> 2191 2241 </li> 2192 2242 <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul> 2193 <li>Warning header field <a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3. 1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>2243 <li>Warning header field <a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3.4</a>, <a href="#rfc.xref.header.warning.4">4.3.5</a>, <a href="#rfc.iref.w.1"><b>5.5</b></a>, <a href="#rfc.xref.header.warning.5">7.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li> 2194 2244 </ul> 2195 2245 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2371 r2372 29 29 <!ENTITY semantics "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 30 <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY conditional-precedence "<xref target='Part4' x:rel='#precedence' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 32 <!ENTITY partial "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 33 <!ENTITY combining-byte-ranges "<xref target='Part5' x:rel='#combining.byte.ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 35 36 <!ENTITY header-connection "<xref target='Part1' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 37 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 <!ENTITY header-if-match "<xref target='Part4' x:rel='#header.if-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 40 <!ENTITY header-if-none-match "<xref target='Part4' x:rel='#header.if-none-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 41 <!ENTITY header-if-modified-since "<xref target='Part4' x:rel='#header.if-modified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 42 <!ENTITY header-if-unmodified-since "<xref target='Part4' x:rel='#header.if-unmodified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 43 <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 44 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 45 <!ENTITY header-vary "<xref target='Part2' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 439 446 <t> 440 447 Also, note that unsafe requests might invalidate already stored responses; 441 see <xref target="invalidation .after.updates.or.deletions" />.448 see <xref target="invalidation" />. 442 449 </t> 443 450 <t> … … 833 840 be selected; see <xref target="caching.negotiated.responses"/>), it can use 834 841 the conditional request mechanism &conditional; in the forwarded request to 835 give the origin server an opportunity to both select a valid stored 836 response to be used, and to update it. This process is known as 842 give the next inbound server an opportunity to select a valid stored 843 response to use, updating the stored metadata in the process, or to replace 844 the stored response(s) with a new response. This process is known as 837 845 "validating" or "revalidating" the stored response. 838 846 </t> 839 <iref item="validator" /> 840 <t> 841 When sending such a conditional request, a cache adds a 842 <x:dfn>validator</x:dfn> (or more than one), that is used to find 843 out whether a stored response is an equivalent copy of a current 847 848 <section anchor="validation.sent" title="Sending a Validation Request"><iref item="validator" /> 849 <t> 850 When sending a conditional request for cache validation, a cache sends one 851 or more precondition header fields containing <x:dfn>validator</x:dfn> 852 metadata from its stored response(s), which is then compared by recipients 853 to determine whether a stored response is equivalent to a current 844 854 representation of the resource. 845 855 </t> 846 856 <t> 847 One such validator is the <x:ref>If-Modified-Since</x:ref> header field, 848 whose value is that of the <x:ref>Last-Modified</x:ref> header field from 849 the selected (see <xref target="caching.negotiated.responses"/>) stored 850 response, if available. 851 </t> 852 <t> 853 Another is the <x:ref>If-None-Match</x:ref> header field, 854 whose value is that of the <x:ref>ETag</x:ref> header field(s) from 855 relevant responses stored for the primary cache key, if present. However, 856 if any of the stored responses contains only partial content, the cache 857 ought not include its entity-tag in the If-None-Match header field unless 858 the request is for a range that would be fully satisfied by that stored 859 response. 860 </t> 861 862 <t>Cache handling of a response to a conditional request is dependent upon its 863 status code:</t> 864 857 One such validator is the timestamp given in a <x:ref>Last-Modified</x:ref> 858 header field (&header-last-modified;), which can be used in an 859 <x:ref>If-Modified-Since</x:ref> header field for response validation, or 860 in an <x:ref>If-Unmodified-Since</x:ref> or <x:ref>If-Range</x:ref> header 861 field for representation selection (i.e., the client is referring 862 specifically to a previously obtained representation with that timestamp). 863 </t> 864 <t> 865 Another validator is the entity-tag given in an <x:ref>ETag</x:ref> header 866 field (&header-etag;). One or more entity-tags, indicating one or more 867 stored responses, can be used in an <x:ref>If-None-Match</x:ref> header 868 field for response validation, or in an <x:ref>If-Match</x:ref> or 869 <x:ref>If-Range</x:ref> header field for representation selection (i.e., 870 the client is referring specifically to one or more previously obtained 871 representations with the listed entity-tags). 872 </t> 873 </section> 874 875 <section anchor="validation.received" title="Handling a Received Validation Request"> 876 <t> 877 Each client in the request chain may have its own cache, so it is common 878 for a cache at an intermediary or origin server to receive conditional 879 requests from other (outbound) caches. Likewise, some user agents make use 880 of conditional requests to limit data transfers to recently modified 881 representations or to complete the transfer of partially retrieved 882 representations. 883 </t> 884 <t> 885 If the request semantics can be satisfied with a cached response and a 886 recipient cache has at least one response stored for this primary cache 887 key, the cache &MUST; evaluate received precondition header fields as part 888 of its selection process for determining a suitable response. 889 A cache &MUST-NOT; evaluate received precondition header fields in a 890 request with semantics that cannot be satisfied with a cached response, or 891 for which the cache has no prior stored responses, since such preconditions 892 are intended for some other (inbound) server. 893 </t> 894 <t> 895 The proper evaluation of conditional requests by a cache depends on the 896 received precondition header fields and their precedence, as defined in 897 &conditional-precedence;. 898 </t> 899 <t> 900 A request containing an <x:ref>If-Match</x:ref> header field 901 (&header-if-match;) indicates that the client wants to receive an error 902 response if the cache has a stored response that cannot be used to answer 903 this request. 904 The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref> 905 response if the field-value is "*" and no suitable response is stored, or 906 if the field-value is a list of entity-tags and none of them match the 907 entity-tag of a suitable stored response. 908 Otherwise, the cache &MUST; generate a <x:ref>2xx (Successful)</x:ref> 909 response that reuses the most recent of its matching stored responses to 910 satisfy the request. 911 </t> 912 <t> 913 A request containing an <x:ref>If-Unmodified-Since</x:ref> header field 914 (&header-if-unmodified-since;) indicates that the client wants to receive 915 an error response if the cache has a stored response that cannot be used 916 to answer this request. 917 The cache &MUST; generate a <x:ref>412 (Precondition Failed)</x:ref> 918 response if one of the following is true: 919 1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that 920 is more recent than the conditional timestamp; 921 2) no <x:ref>Last-Modified</x:ref> field is present, but a stored 922 response has a <x:ref>Date</x:ref> field-value that is more recent than the 923 conditional timestamp; or, 924 3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present, 925 but the cache recorded a stored response as having been received at a 926 time more recent than the conditional timestamp. 927 Otherwise, the cache &MUST; generate a <x:ref>2xx (Successful)</x:ref> 928 response that reuses the most recent of its matching stored responses to 929 satisfy the request. 930 </t> 931 <t> 932 A request containing an <x:ref>If-None-Match</x:ref> header field 933 (&header-if-none-match;) indicates that the client wants to validate one 934 or more of its stored responses. 935 If the field-value is "*" and any suitable response is 936 stored, or the field-value is a list of entity-tags and at least one of 937 them match the entity-tag of a suitable stored response, the cache &MUST; 938 generate a <x:ref>304 (Not Modified)</x:ref> response using the most 939 suitable of those matching responses as the selected representation. 940 Otherwise, if the cache has one or more suitable stored responses that 941 do not match the condition, the cache &MUST; generate a 942 <x:ref>2xx (Successful)</x:ref> response that reuses the most suitable of 943 those stored responses to satisfy the request. 944 Finally, if the cache has no suitable stored responses, the cache &SHOULD; 945 forward the conditional request toward the origin server; if the received 946 condition contains a list of entity-tags and the cache has its own set of 947 stored responses for that primary cache key, the cache &SHOULD; take the 948 union of the received set with the set of entity-tags for its own stored 949 set of responses (fresh or stale) and generate an 950 <x:ref>If-None-Match</x:ref> header field containing that union when it 951 forwards the request toward the origin server. 952 However, if a stored responses contains only partial content, the cache 953 &MUST-NOT; include its entity-tag in the union unless the request is for 954 a range that would be fully satisfied by that stored response. 955 </t> 956 <t> 957 A request containing an <x:ref>If-Modified-Since</x:ref> header field 958 (&header-if-modified-since;) indicates that the client wants to validate 959 one or more of its stored responses by modification date if the stored 960 responses have no entity-tag or the recipient does not implement 961 <x:ref>If-None-Match</x:ref>. 962 The cache &MUST; generate a <x:ref>2xx (Successful)</x:ref> response, 963 reusing the most recent of its stored responses to satisfy the request, 964 if one of the following is true: 965 1) a stored response has a <x:ref>Last-Modified</x:ref> field-value that 966 is more recent than the conditional timestamp; 967 2) no <x:ref>Last-Modified</x:ref> field is present, but a stored 968 response has a <x:ref>Date</x:ref> field-value that is more recent than the 969 conditional timestamp; or, 970 3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present, 971 but the cache recorded a stored response as having been received at a 972 time more recent than the conditional timestamp. 973 Otherwise, if the cache has one or more suitable stored responses, the 974 cache &MUST; generate a <x:ref>304 (Not Modified)</x:ref> response using 975 the most recent of its suitable stored responses as the selected 976 representation. 977 Finally, if the cache has no suitable stored responses, the cache &SHOULD; 978 forward the conditional request toward the origin server. 979 </t> 980 <t> 981 A cache that implements partial responses to range requests, as defined in 982 &partial;, also needs to evaluate a received <x:ref>If-Range</x:ref> header 983 field (&header-if-range;) in respect to its selected stored response. 984 </t> 985 </section> 986 987 <section anchor="validation.response" title="Handling a Validation Response"> 988 <t> 989 Cache handling of a response to a conditional request is dependent upon its 990 status code: 991 </t> 865 992 <t> 866 993 <list style="symbols"> … … 873 1000 A full response (i.e., one with a payload body) indicates that none 874 1001 of the stored responses nominated in the conditional request is 875 suitable. Instead, the cache canuse the full response to1002 suitable. Instead, the cache &MUST; use the full response to 876 1003 satisfy the request and &MAY; replace the stored response(s). 877 1004 </t> … … 880 1007 response while attempting to validate a response, it can either 881 1008 forward this response to the requesting client, or act as if the 882 server failed to respond. In the latter case, it cansend a1009 server failed to respond. In the latter case, the cache &MAY; send a 883 1010 previously stored response (see <xref 884 1011 target="serving.stale.responses" />). … … 886 1013 </list> 887 1014 </t> 1015 </section> 888 1016 889 1017 <section anchor="freshening.responses" title="Freshening Stored Responses upon Validation"> … … 936 1064 </section> 937 1065 938 </section> 939 940 </section> 941 942 943 <section anchor="head.effects" title="Updating Caches with HEAD Responses"> 1066 <section anchor="head.effects" title="Freshening Responses via HEAD"> 944 1067 <t> 945 1068 A response to the HEAD method is identical to what an equivalent request 946 1069 made with a GET would have been, except it lacks a body. This property 947 of HEAD responses is used to both invalidate and update cached GET 948 responses. 1070 of HEAD responses can be used to invalidate or update a cached GET 1071 response if the more efficient conditional GET request mechanism is not 1072 available (due to no validators being present in the stored response) or 1073 if transmission of the representation body is not desired even if it has 1074 changed. 949 1075 </t> 950 1076 <t> … … 968 1094 <t>retain any <x:ref>Warning</x:ref> header fields in the stored response 969 1095 with warn-code 2xx; and,</t> 970 <t>use other header fields provided in the response to replace1096 <t>use other header fields provided in the HEAD response to replace 971 1097 all instances of the corresponding header fields in the stored 972 1098 response.</t> 973 1099 </list> 974 1100 </t> 975 976 </section> 977 978 979 <section anchor="invalidation.after.updates.or.deletions" 980 title="Request Methods that Invalidate"> 1101 </section> 1102 </section> 1103 1104 1105 <section anchor="invalidation" title="Invalidation"> 981 1106 <t> 982 1107 Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE … … 1015 1140 might be stored in other caches that it has not.</t> 1016 1141 </section> 1017 1142 </section> 1018 1143 1019 1144 … … 2157 2282 <x:defines>304</x:defines> 2158 2283 <x:defines>304 (Not Modified)</x:defines> 2284 <x:defines>412 (Precondition Failed)</x:defines> 2159 2285 <x:defines>ETag</x:defines> 2160 2286 <x:defines>If-Modified-Since</x:defines> 2287 <x:defines>If-Unmodified-Since</x:defines> 2288 <x:defines>If-Match</x:defines> 2161 2289 <x:defines>If-None-Match</x:defines> 2162 2290 <x:defines>Last-Modified</x:defines> … … 2185 2313 <x:defines>206 (Partial Content)</x:defines> 2186 2314 <x:defines>Content-Range</x:defines> 2315 <x:defines>If-Range</x:defines> 2187 2316 <x:defines>Range</x:defines> 2188 2317 </x:source> … … 2396 2525 Requirements regarding denial of service attack avoidance when performing 2397 2526 invalidation have been clarified. 2398 (<xref target="invalidation .after.updates.or.deletions" />)2527 (<xref target="invalidation" />) 2399 2528 </t> 2400 2529 <t> 2401 2530 Cache invalidation only occurs when a successful response is received. 2402 (<xref target="invalidation .after.updates.or.deletions" />)2531 (<xref target="invalidation" />) 2403 2532 </t> 2404 2533 <t>
Note: See TracChangeset
for help on using the changeset viewer.