Changeset 1803 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 16/07/12 10:13:57 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1799 r1803 452 452 } 453 453 @bottom-center { 454 content: "Expires January 1 6, 2013";454 content: "Expires January 17, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 5">500 <meta name="dct.issued" scheme="ISO8601" content="2012-07-16"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: January 1 6, 2013</td>526 <td class="left">Expires: January 17, 2013</td> 527 527 <td class="right">M. Nottingham, Editor</td> 528 528 </tr> … … 541 541 <tr> 542 542 <td class="left"></td> 543 <td class="right">July 1 5, 2012</td>543 <td class="right">July 16, 2012</td> 544 544 </tr> 545 545 </tbody> … … 570 570 in progress”. 571 571 </p> 572 <p>This Internet-Draft will expire on January 1 6, 2013.</p>572 <p>This Internet-Draft will expire on January 17, 2013.</p> 573 573 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 574 574 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 789 789 <p id="rfc.section.1.3.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 790 790 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 791 or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.791 or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> for definitions of these terms. 792 792 </p> 793 793 <p id="rfc.section.1.3.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely … … 807 807 </p> 808 808 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 809 <p id="rfc.section.1.4.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded.809 <p id="rfc.section.1.4.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 810 810 </p> 811 811 <p id="rfc.section.1.4.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 814 814 </p> 815 815 <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 816 <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:817 </p> 818 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>819 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>820 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>816 <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>: 817 </p> 818 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 819 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 820 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 821 821 </pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 822 822 <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p> 823 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>824 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>>825 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.8</a>>826 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a>>827 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.8</a>>823 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 824 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>> 825 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.8</a>> 826 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a>> 827 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.8</a>> 828 828 </pre><h3 id="rfc.section.1.4.3"><a href="#rfc.section.1.4.3">1.4.3</a> <a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3> 829 829 <p id="rfc.section.1.4.3.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p> … … 835 835 <div id="rfc.iref.c.5"></div> 836 836 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Overview of Cache Operation</a></h1> 837 <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when837 <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when 838 838 no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing 839 839 a cache from either storing a non-reusable response or reusing a stored response inappropriately. … … 887 887 </p> 888 888 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2> 889 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200889 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200 890 890 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 891 891 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields. 892 892 </p> 893 <p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 4.4</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies893 <p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 4.4</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies 894 894 a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code. 895 895 </p> … … 907 907 </p> 908 908 <ul> 909 <li>The presented 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.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and909 <li>The presented 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.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) and that of the stored response match, and 910 910 </li> 911 911 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 931 931 <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> include a single <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>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>. 932 932 </p> 933 <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 2.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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 request933 <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 2.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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 934 934 and having received a corresponding response. 935 935 </p> … … 985 985 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3> 986 986 <p id="rfc.section.4.1.2.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness 987 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial987 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial 988 988 Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved 989 989 Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it. … … 1018 1018 <ul class="empty"> 1019 1019 <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value" 1020 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.1020 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 1021 1021 </li> 1022 1022 </ul> … … 1149 1149 <ul> 1150 1150 <li>adding or removing whitespace, where allowed in the header field's syntax</li> 1151 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)1151 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) 1152 1152 </li> 1153 1153 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification … … 1169 1169 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2> 1170 1170 <p id="rfc.section.4.4.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or 1171 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the1172 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.1171 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the 1172 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. 1173 1173 </p> 1174 1174 <p id="rfc.section.4.4.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: … … 1200 1200 </ul> 1201 1201 <h1 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> 1202 <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 2.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them1202 <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 2.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 1203 1203 to keep their contents up-to-date. 1204 1204 </p> 1205 <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.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.1206 </p> 1207 <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.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.1208 </p> 1209 <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.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.1205 <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.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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. 1206 </p> 1207 <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.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). This helps prevent denial of service attacks. 1208 </p> 1209 <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.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. 1210 1210 </p> 1211 1211 <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, … … 1487 1487 that time. 1488 1488 </p> 1489 <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.1489 <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format. 1490 1490 </p> 1491 1491 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.expires" class="smpl">Expires</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> … … 1891 1891 </p> 1892 1892 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1893 <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1893 <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. 1894 1894 </p> 1895 1895 <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References … … 1900 1900 <tr> 1901 1901 <td class="reference"><b id="Part1">[Part1]</b></td> 1902 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), July 2012.1902 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), July 2012. 1903 1903 </td> 1904 1904 </tr> 1905 1905 <tr> 1906 1906 <td class="reference"><b id="Part2">[Part2]</b></td> 1907 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), July 2012.1907 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), July 2012. 1908 1908 </td> 1909 1909 </tr> … … 1915 1915 <tr> 1916 1916 <td class="reference"><b id="Part5">[Part5]</b></td> 1917 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), July 2012.1917 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), July 2012. 1918 1918 </td> 1919 1919 </tr>
Note: See TracChangeset
for help on using the changeset viewer.