Changeset 1740 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 08/07/12 18:15:03 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1739 r1740 794 794 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 795 795 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 796 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type797 of error recoverycould lead to dangerous consequences.796 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 797 could lead to dangerous consequences. 798 798 </p> 799 799 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 913 913 <p id="rfc.section.2.2.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 2.6</a>. 914 914 </p> 915 <p id="rfc.section.2.2.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 Date header field). It can also forward a request with "Cache-Control:916 max-age=0" or "Cache-Control: no-cache" to disambiguatewhich response to use.915 <p id="rfc.section.2.2.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 a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate 916 which response to use. 917 917 </p> 918 918 <p id="rfc.section.2.2.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard. … … 951 951 <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) is present, use its value, or 952 952 </li> 953 <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 3.3</a>) is present, use its value minus the value of the Dateresponse header field, or953 <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 3.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 954 954 </li> 955 955 <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 2.3.1.1</a>. … … 993 993 </p> 994 994 <ul class="empty"> 995 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 996 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 997 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. 995 <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" 996 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. 998 997 </li> 999 998 </ul> … … 1138 1137 to keep their contents up-to-date. 1139 1138 </p> 1140 <p id="rfc.section.2.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.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response 1141 to a request with an unsafe method is received. 1142 </p> 1143 <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host 1144 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.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1139 <p id="rfc.section.2.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.13"><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. 1140 </p> 1141 <p id="rfc.section.2.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.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1145 1142 </p> 1146 1143 <p id="rfc.section.2.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.15"><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. … … 1184 1181 </p> 1185 1182 <p id="rfc.section.2.8.p.5">The stored response with matching selecting header fields is known as the selected response.</p> 1186 <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the Dateheader field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 2.2</a>.1183 <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 2.2</a>. 1187 1184 </p> 1188 1185 <p id="rfc.section.2.8.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request; … … 1305 1302 <div id="rfc.iref.n.3"></div> 1306 1303 <h4 id="rfc.section.3.2.1.6"><a href="#rfc.section.3.2.1.6">3.2.1.6</a> <a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4> 1307 <p id="rfc.section.3.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> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Typerequest header fields, nor the request representation.1304 <p id="rfc.section.3.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> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> request header fields, nor the request representation. 1308 1305 </p> 1309 1306 <div id="rfc.iref.c.13"></div> … … 1421 1418 <div id="rfc.iref.n.6"></div> 1422 1419 <h4 id="rfc.section.3.2.2.9"><a href="#rfc.section.3.2.2.9">3.2.2.9</a> <a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4> 1423 <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Typeresponse header fields, nor the response representation.1420 <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> response header fields, nor the response representation. 1424 1421 </p> 1425 1422 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> … … 1592 1589 </ul> 1593 1590 <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning header fields to a receiver whose version is HTTP/1.0 or lower, 1594 then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message. 1595 </p> 1596 <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date 1597 value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning 1591 then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message. 1592 </p> 1593 <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the <a href="p2-semantics.html#header.date" class="smpl">Date</a> value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning 1598 1594 header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well. 1599 1595 </p> … … 1970 1966 <p id="rfc.section.A.p.1">Make the specified age calculation algorithm less conservative. (<a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>) 1971 1967 </p> 1972 <p id="rfc.section.A.p.2">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to 1973 use. (<a href="#validation.model" title="Validation Model">Section 2.4</a>) 1968 <p id="rfc.section.A.p.2">Remove requirement to consider <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> in successful responses in order to determine the appropriate response to use. (<a href="#validation.model" title="Validation Model">Section 2.4</a>) 1974 1969 </p> 1975 1970 <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.6</a>)
Note: See TracChangeset
for help on using the changeset viewer.