Changeset 1314 for draft-ietf-httpbis/latest
- Timestamp:
- 29/06/11 01:27:43 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1303 r1314 362 362 } 363 363 @bottom-center { 364 content: "Expires December 3 , 2011";364 content: "Expires December 31, 2011"; 365 365 } 366 366 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-06- 01">410 <meta name="dct.issued" scheme="ISO8601" content="2011-06-29"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: December 3 , 2011</td>436 <td class="left">Expires: December 31, 2011</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">June 1, 2011</td>497 <td class="right">June 29, 2011</td> 498 498 </tr> 499 499 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on December 3 , 2011.</p>525 <p>This Internet-Draft will expire on December 31, 2011.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 968 968 to keep their contents up-to-date. 969 969 </p> 970 <p id="rfc.section.2.5.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when requests with unsafe methods971 arereceived.970 <p id="rfc.section.2.5.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request 971 with an unsafe method is received. 972 972 </p> 973 973 <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part 974 974 in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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. 975 975 </p> 976 <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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 passing through requests with methods whose safety is unknown. 977 </p> 978 <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will 979 mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. 976 <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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. 977 </p> 978 <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all 979 stored responses related to the effective request URI, or will mark these as "invalid" and in need of a mandatory validation 980 before they can be returned in response to a subsequent request. 980 981 </p> 981 982 <p id="rfc.section.2.5.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the … … 1971 1972 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/289">http://tools.ietf.org/wg/httpbis/trac/ticket/289</a>>: "Proxies don't 'understand' methods" 1972 1973 </li> 1974 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/235">http://tools.ietf.org/wg/httpbis/trac/ticket/235</a>>: "Cache Invalidation only happens upon successful responses" 1975 </li> 1973 1976 </ul> 1974 1977 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> -
draft-ietf-httpbis/latest/p6-cache.xml
r1303 r1314 882 882 caches can use them to keep their contents up-to-date. 883 883 </t> 884 885 Here, a non-error response is one with a 2xx or 3xx status code. 886 884 887 <t> 885 888 A cache &MUST; invalidate the effective Request URI 886 889 (&effective-request-uri;) as well as the URI(s) in the Location 887 and Content-Location header fields (if present) when requests with888 unsafe methods arereceived.890 and Content-Location header fields (if present) when a non-error 891 response to a request with an unsafe method is received. 889 892 </t> 890 893 <t> … … 896 899 <t> 897 900 A cache &SHOULD; invalidate the effective request URI 898 (&effective-request-uri;) when passing through requests with methods 899 whose safety is unknown. 900 </t> 901 <t> 902 Here, "invalidate" means that the cache will either remove all stored 901 (&effective-request-uri;) when it receives a non-error response 902 to a request with a method whose safety is unknown. 903 </t> 904 <t> 905 Here, a "non-error response" is one with a 2xx or 3xx status code. 906 "Invalidate" means that the cache will either remove all stored 903 907 responses related to the effective request URI, or will mark these as 904 908 "invalid" and in need of a mandatory validation before they can be returned … … 2723 2727 "Proxies don't 'understand' methods" 2724 2728 </t> 2729 <t> 2730 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/235"/>: 2731 "Cache Invalidation only happens upon successful responses" 2732 </t> 2725 2733 </list> 2726 2734 </t>
Note: See TracChangeset
for help on using the changeset viewer.