Changeset 1740 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 08/07/12 18:15:03 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r1739 r1740 332 332 impact on security. This is because different uses of the protocol require 333 333 different error handling strategies; for example, a Web browser might wish to 334 transparently recover from a response where the Location header field 335 doesn't parse according to the ABNF, whereby in a systems control protocol 336 using HTTP, this type of error recovery could lead to dangerous consequences. 334 transparently recover from a response where the <x:ref>Location</x:ref> 335 header field doesn't parse according to the ABNF, whereby in a systems 336 control protocol using HTTP, this type of error recovery could lead to 337 dangerous consequences. 337 338 </t> 338 339 </section> … … 580 581 <t> 581 582 When more than one suitable response is stored, a cache &MUST; use the 582 most recent response (as determined by the Date header field). It can also583 f orward a request with "Cache-Control: max-age=0" or "Cache-Control:584 no-cache" to disambiguate which response to use.583 most recent response (as determined by the <x:ref>Date</x:ref> header 584 field). It can also forward a request with "Cache-Control: max-age=0" or 585 "Cache-Control: no-cache" to disambiguate which response to use. 585 586 </t> 586 587 <t> … … 662 663 <t>If the <x:ref>Expires</x:ref> response header field 663 664 (<xref target="header.expires" />) is present, use its value minus the 664 value of the Dateresponse header field, or</t>665 value of the <x:ref>Date</x:ref> response header field, or</t> 665 666 <t>Otherwise, no explicit expiration time is present in the response. A 666 667 heuristic freshness lifetime might be applicable; see <xref … … 742 743 <list> 743 744 <t> 744 HTTP/1.1 requires origin servers to send a Date header field, if possible,745 with every response, giving the time at which the response was746 generated. The term "date_value" denotes the value of the Date747 header field, in a form appropriate for arithmetic operations. See745 HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header 746 field, if possible, with every response, giving the time at which the 747 response was generated. The term "date_value" denotes the value of the 748 Date header field, in a form appropriate for arithmetic operations. See 748 749 &header-date; for the definition of the Date header field, and for 749 750 requirements regarding responses without it. … … 1022 1023 <t> 1023 1024 A cache &MUST; invalidate the effective Request URI 1024 (&effective-request-uri;) as well as the URI(s) in the Location1025 and Content-Location response header fields (if present) when a non-error1026 response to a request with an unsafe method is received.1027 </t> 1028 <t> 1029 However, a cache &MUST-NOT; invalidate a URI from a Location or1030 Content-Location response header field if the host part of that URI differs1031 from the host part in the effective request URI (&effective-request-uri;).1032 This helps prevent denial of service attacks.1025 (&effective-request-uri;) as well as the URI(s) in the <x:ref>Location</x:ref> 1026 and <x:ref>Content-Location</x:ref> response header fields (if present) when 1027 a non-error response to a request with an unsafe method is received. 1028 </t> 1029 <t> 1030 However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref> 1031 or <x:ref>Content-Location</x:ref> response header field if the host part of 1032 that URI differs from the host part in the effective request URI 1033 (&effective-request-uri;). This helps prevent denial of service attacks. 1033 1034 </t> 1034 1035 <t> … … 1122 1123 <t> 1123 1124 If multiple selected responses are available, the most recent response 1124 (as determined by the Dateheader field) is used; see <xref1125 (as determined by the <x:ref>Date</x:ref> header field) is used; see <xref 1125 1126 target="constructing.responses.from.caches"/>. 1126 1127 </t> … … 1360 1361 The no-transform request directive indicates that an intermediary 1361 1362 (whether or not it implements a cache) &MUST-NOT; change the 1362 Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type request 1363 header fields, nor the request representation. 1363 <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or 1364 <x:ref>Content-Type</x:ref> request header fields, nor the request 1365 representation. 1364 1366 </t> 1365 1367 </section> … … 1589 1591 The no-transform response directive indicates that an intermediary 1590 1592 (regardless of whether it implements a cache) &MUST-NOT; change the 1591 Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type response 1592 header fields, nor the response representation. 1593 <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or 1594 <x:ref>Content-Type</x:ref> response header fields, nor the response 1595 representation. 1593 1596 </t> 1594 1597 </section> … … 1912 1915 If an implementation sends a message with one or more Warning header fields to a 1913 1916 receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include 1914 in each warning-value a warn-date that matches the Date header field in the1915 message.1917 in each warning-value a warn-date that matches the <x:ref>Date</x:ref> header 1918 field in the message. 1916 1919 </t> 1917 1920 <t> 1918 1921 If a system receives a message with a warning-value that includes 1919 a warn-date, and that warn-date is different from the Date value in the1920 response, then that warning-value &MUST; be deleted from the message before1921 storing, forwarding, or using it. (preventing the consequences of naive1922 caching of Warning header fields.) If all of the warning-values are deleted1923 for this reason, the Warning header field &MUST; be deleted as well.1922 a warn-date, and that warn-date is different from the <x:ref>Date</x:ref> 1923 value in the response, then that warning-value &MUST; be deleted from the 1924 message before storing, forwarding, or using it. (preventing the consequences 1925 of naive caching of Warning header fields.) If all of the warning-values are 1926 deleted for this reason, the Warning header field &MUST; be deleted as well. 1924 1927 </t> 1925 1928 <t> … … 2309 2312 <x:defines>5xx (Server Error)</x:defines> 2310 2313 <x:defines>504 (Gateway Timeout)</x:defines> 2314 <x:defines>Content-Encoding</x:defines> 2315 <x:defines>Content-Location</x:defines> 2316 <x:defines>Content-Type</x:defines> 2317 <x:defines>Date</x:defines> 2318 <x:defines>Location</x:defines> 2311 2319 </x:source> 2312 2320 </reference> … … 2532 2540 </t> 2533 2541 <t> 2534 Remove requirement to consider Content-Location in successful responses2535 in order to determine the appropriate response to use.2542 Remove requirement to consider <x:ref>Content-Location</x:ref> in successful 2543 responses in order to determine the appropriate response to use. 2536 2544 (<xref target="validation.model" />) 2537 2545 </t>
Note: See TracChangeset
for help on using the changeset viewer.