Changeset 1746
- Timestamp:
- 09/07/12 07:51:48 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r1745 r1746 406 406 If an implementation receives a delta-seconds value larger than the largest 407 407 positive integer it can represent, or if any of its subsequent calculations 408 overflows, it &MUST; consider the value to be 2147483648 (2<x:sup>31</x:sup>).409 Recipients parsing a delta-seconds value &MUST; use an arithmetic type of410 a t least 31 bits of range, and senders &MUST-NOT; send delta-seconds with a411 value greater than 2147483648.408 overflows, it &MUST; consider the value to be 2147483648 409 (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use 410 an arithmetic type of at least 31 bits of range, and senders &MUST-NOT; 411 send delta-seconds with a value greater than 2147483648. 412 412 </t> 413 413 </section> … … 431 431 <t> 432 432 Each <x:dfn>cache entry</x:dfn> consists of a cache key and one or more 433 HTTP responses corresponding to prior requests that used the same key. 434 The most common form of cache entry is a successful result of a retrieval 435 request: i.e., a <x:ref>200 (OK)</x:ref> response containing a representation 436 of the resource identified by the request target. However, it is also possible 437 to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results 438 (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than 439 GET if the method's definition allows such caching and defines something 440 suitable for use as a cache key. 433 HTTP responses corresponding to prior requests that used the same key. The 434 most common form of cache entry is a successful result of a retrieval 435 request: i.e., a <x:ref>200 (OK)</x:ref> response containing a 436 representation of the resource identified by the request target. However, 437 it is also possible to cache negative results (e.g., <x:ref>404 (Not 438 Found)</x:ref>, incomplete results (e.g., <x:ref>206 (Partial 439 Content)</x:ref>), and responses to safe methods other than GET if the 440 method's definition allows such caching and defines something suitable for 441 use as a cache key. 441 442 </t> 442 443 <t> … … 466 467 target="cache-response-directive" />) does not appear in the response, if 467 468 the cache is shared, and</t> 468 <t>the <x:ref>Authorization</x:ref> header field (see &header-authorization;) does not469 appear in the request, if the cache is shared, unless the response470 explicitly allows it (see <xref target="caching.authenticated.responses"471 />), and</t>469 <t>the <x:ref>Authorization</x:ref> header field (see 470 &header-authorization;) does not appear in the request, if the cache is 471 shared, unless the response explicitly allows it (see <xref 472 target="caching.authenticated.responses" />), and</t> 472 473 <t>the response either: 473 474 <list style="symbols"> … … 503 504 </t> 504 505 <t> 505 A response message is considered complete when all of the octets 506 indicated by the message framing (&messaging;) are received507 prior to the connection being closed. If the request is GET, the response508 status is <x:ref>200 (OK)</x:ref>, and the entire509 response header block has been received, a cache &MAY; store an incomplete510 re sponse message body if the cache entry is recorded as incomplete.511 Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were512 an incomplete <x:ref>200 (OK)</x:ref> cache entry. However, a cache &MUST-NOT; store513 incomplete or partial content responses if it does not support the514 <x:ref>Range</x:ref> and <x:ref>Content-Range</x:ref> header fields or if it515 does not understandthe range units used in those fields.506 A response message is considered complete when all of the octets indicated 507 by the message framing (&messaging;) are received prior to the connection 508 being closed. If the request is GET, the response status is <x:ref>200 509 (OK)</x:ref>, and the entire response header block has been received, a 510 cache &MAY; store an incomplete response message body if the cache entry is 511 recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref> 512 response &MAY; be stored as if it were an incomplete <x:ref>200 513 (OK)</x:ref> cache entry. However, a cache &MUST-NOT; store incomplete or 514 partial content responses if it does not support the <x:ref>Range</x:ref> 515 and <x:ref>Content-Range</x:ref> header fields or if it does not understand 516 the range units used in those fields. 516 517 </t> 517 518 <t> 518 519 A cache &MAY; complete a stored incomplete response by making a subsequent 519 520 range request (&partial;) and combining the successful response with the 520 stored entry, as defined in <xref target="combining.responses"/>. 521 A cache &MUST-NOT; use an incomplete response to answer requests522 unless the response has been made complete or the request is partial and523 specifies a range that is wholly within the incomplete response.524 A cache &MUST-NOT; send a partial response to a client without explicitly525 marking it as suchusing the <x:ref>206 (Partial Content)</x:ref> status code.521 stored entry, as defined in <xref target="combining.responses"/>. A cache 522 &MUST-NOT; use an incomplete response to answer requests unless the 523 response has been made complete or the request is partial and specifies a 524 range that is wholly within the incomplete response. A cache &MUST-NOT; 525 send a partial response to a client without explicitly marking it as such 526 using the <x:ref>206 (Partial Content)</x:ref> status code. 526 527 </t> 527 528 </section> … … 570 571 </t> 571 572 <t> 572 A cache &MUST; write through requests with methods that are unsafe 573 (&safe-methods;) to the origin server; i.e., a cache is not allowed to generate574 a reply to such a request before having forwarded the request and having575 received a corresponding response.573 A cache &MUST; write through requests with methods that are unsafe 574 (&safe-methods;) to the origin server; i.e., a cache is not allowed to 575 generate a reply to such a request before having forwarded the request and 576 having received a corresponding response. 576 577 </t> 577 578 <t> … … 586 587 </t> 587 588 <t> 588 A cache that does not have a clock available &MUST-NOT; use stored responses 589 without revalidating them on every use. A cache, especially a shared 590 cache, &SHOULD; use a mechanism, such as NTP <xref target="RFC1305"/>, to 591 synchronize its clock with a reliable external standard. 589 A cache that does not have a clock available &MUST-NOT; use stored 590 responses without revalidating them on every use. A cache, especially a 591 shared cache, &SHOULD; use a mechanism, such as NTP <xref 592 target="RFC1305"/>, to synchronize its clock with a reliable external 593 standard. 592 594 </t> 593 595 … … 602 604 <t> 603 605 The primary mechanism for determining freshness is for an origin server to 604 provide an explicit expiration time in the future, using either the <x:ref>Expires</x:ref> 605 header field (<xref target="header.expires" />) or the max-age response cache 606 directive (<xref target="cache-response-directive" />). Generally, origin 607 servers will assign future explicit expiration times to responses in the 608 belief that the representation is not likely to change in a semantically 609 significant way before the expiration time is reached. 606 provide an explicit expiration time in the future, using either the 607 <x:ref>Expires</x:ref> header field (<xref target="header.expires" />) or 608 the max-age response cache directive (<xref 609 target="cache-response-directive" />). Generally, origin servers will 610 assign future explicit expiration times to responses in the belief that the 611 representation is not likely to change in a semantically significant way 612 before the expiration time is reached. 610 613 </t> 611 614 <t> … … 617 620 </t> 618 621 <t> 619 Since origin servers do not always provide explicit expiration times, 620 acache &MAY; assign a heuristic expiration time when an explicit time is not621 specified, employing algorithms that use other header field values (such as the622 <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time.623 This specification does not provide specific algorithms, but does impose624 worst-case constraints on their results.622 Since origin servers do not always provide explicit expiration times, a 623 cache &MAY; assign a heuristic expiration time when an explicit time is not 624 specified, employing algorithms that use other header field values (such as 625 the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration 626 time. This specification does not provide specific algorithms, but does 627 impose worst-case constraints on their results. 625 628 </t> 626 629 <figure> … … 684 687 If no explicit expiration time is present in a stored response that has a 685 688 status code whose definition allows heuristic freshness to be used 686 (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203 687 (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>, 688 <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and 689 <x:ref>410 (Gone)</x:ref>), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT; 690 use heuristics to determine freshness for responses with status codes that do 691 not explicitly allow it. 689 (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>, 690 <x:ref>203 (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial 691 Content)</x:ref>, <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved 692 Permanently)</x:ref> and <x:ref>410 (Gone)</x:ref>), a cache &MAY; 693 calculate a heuristic expiration time. A cache &MUST-NOT; use heuristics to 694 determine freshness for responses with status codes that do not explicitly 695 allow it. 692 696 </t> 693 697 <t> … … 720 724 HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated 721 725 age of the response message when obtained from a cache. The Age field value 722 is the cache's estimate of the amount of time since the response was generated or723 validated by the origin server. In essence, the Age value is the sum of the724 t ime that the response has been resident in each of the caches alongthe725 path from the origin server, plus the amount of time it has been in transit726 along network paths.726 is the cache's estimate of the amount of time since the response was 727 generated or validated by the origin server. In essence, the Age value is 728 the sum of the time that the response has been resident in each of the 729 caches along the path from the origin server, plus the amount of time it 730 has been in transit along network paths. 727 731 </t> 728 732 <t> … … 745 749 HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header 746 750 field, if possible, with every response, giving the time at which the 747 response was generated. The term "date_value" denotes the value of the748 Date header field, in a form appropriate for arithmetic operations. See749 &header-date; for the definition of the Date header field, and for750 requirements regarding responses without it.751 response was generated. The term "date_value" denotes the value of 752 the Date header field, in a form appropriate for arithmetic 753 operations. See &header-date; for the definition of the Date header 754 field, and for requirements regarding responses without it. 751 755 </t> 752 756 </list> … … 876 880 <t> 877 881 If a cache receives a first-hand response (either an entire response, or a 878 <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the879 requesting client, and the received response is no longer fresh, the cache880 ca n forward it to the requesting client without adding a new <x:ref>Warning</x:ref>881 (but without removing any existing Warning header fields). A cache shouldn't882 attempt to validate a response simply because that response became stale in883 t ransit.882 <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward 883 to the requesting client, and the received response is no longer fresh, the 884 cache can forward it to the requesting client without adding a new 885 <x:ref>Warning</x:ref> (but without removing any existing Warning header 886 fields). A cache shouldn't attempt to validate a response simply because 887 that response became stale in transit. 884 888 </t> 885 889 </section> … … 912 916 </t> 913 917 914 <t>Cache handling of a response to a conditional request is dependent upon its status code:</t> 918 <t>Cache handling of a response to a conditional request is dependent upon its 919 status code:</t> 915 920 916 921 <t> 917 922 <list style="symbols"> 918 923 <t> 919 A <x:ref>304 (Not Modified)</x:ref> response status code indicates that the stored920 response can be updated and reused; see <xref924 A <x:ref>304 (Not Modified)</x:ref> response status code indicates 925 that the stored response can be updated and reused; see <xref 921 926 target="freshening.responses"/>. 922 927 </t> … … 932 937 forward this response to the requesting client, or act as if the 933 938 server failed to respond. In the latter case, it can return a 934 previously stored response (see <xref target="serving.stale.responses" />). 939 previously stored response (see <xref 940 target="serving.stale.responses" />). 935 941 </t> 936 942 </list> … … 939 945 <section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified"> 940 946 <t> 941 When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one942 or more stored <x:ref>200 (OK)</x:ref> responses for the same cache key, the cache needs943 to identify which of the stored responses are updated by this new response944 a nd then update the stored response(s) with the new information provided in945 the <x:ref>304</x:ref> response.947 When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and 948 already has one or more stored <x:ref>200 (OK)</x:ref> responses for the 949 same cache key, the cache needs to identify which of the stored responses 950 are updated by this new response and then update the stored response(s) 951 with the new information provided in the <x:ref>304</x:ref> response. 946 952 <list style="symbols"> 947 953 <t> … … 1023 1029 </t> 1024 1030 <t> 1025 A cache &MUST; invalidate the effective Request URI 1026 (&effective-request-uri;) as well as the URI(s) in the <x:ref>Location</x:ref> 1027 and <x:ref>Content-Location</x:ref> response header fields (if present) when 1028 a non-error response to a request with an unsafe method is received. 1031 A cache &MUST; invalidate the effective Request URI 1032 (&effective-request-uri;) as well as the URI(s) in the 1033 <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header 1034 fields (if present) when a non-error response to a request with an unsafe 1035 method is received. 1029 1036 </t> 1030 1037 <t> … … 1040 1047 </t> 1041 1048 <t> 1042 Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> or 1043 <x:ref>3xx (Redirection)</x:ref> status code. 1044 "Invalidate" means that the cache will either remove all stored 1045 responses related to the effective request URI, or will mark these as 1046 "invalid" and in need of a mandatory validation before they can be returned 1047 in response to a subsequent request. 1049 Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> 1050 or <x:ref>3xx (Redirection)</x:ref> status code. "Invalidate" means that 1051 the cache will either remove all stored responses related to the effective 1052 request URI, or will mark these as "invalid" and in need of a mandatory 1053 validation before they can be returned in response to a subsequent request. 1048 1054 </t> 1049 1055 <t> … … 1058 1064 <t> 1059 1065 A shared cache &MUST-NOT; use a cached response to a request with an 1060 <x:ref>Authorization</x:ref> header field (&header-authorization;) to satisfy any subsequent1061 request unless a cache directive that allows such responses to be stored is1062 present in the response.1066 <x:ref>Authorization</x:ref> header field (&header-authorization;) to 1067 satisfy any subsequent request unless a cache directive that allows such 1068 responses to be stored is present in the response. 1063 1069 </t> 1064 1070 … … 1085 1091 that has a <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>), 1086 1092 it &MUST-NOT; use that response unless all of the selecting header fields 1087 nominated by the Vary header field match in both the original request (i.e., 1088 that associated with the stored response), and the presented request. 1093 nominated by the Vary header field match in both the original request 1094 (i.e., that associated with the stored response), and the presented 1095 request. 1089 1096 </t> 1090 1097 <t> … … 1094 1101 <list style="symbols"> 1095 1102 <t> 1096 adding or removing whitespace, where allowed in the header field's syntax 1103 adding or removing whitespace, where allowed in the header field's 1104 syntax 1097 1105 </t> 1098 1106 <t> … … 1102 1110 <t> 1103 1111 normalizing both header field values in a way that is known to have 1104 identical semantics, according to the header field's specification (e.g.,1105 re-ordering field values when order is not significant;1112 identical semantics, according to the header field's specification 1113 (e.g., re-ordering field values when order is not significant; 1106 1114 case-normalization, where values are defined to be case-insensitive) 1107 1115 </t> … … 1372 1380 <iref item="only-if-cached" primary="true" subitem="Cache Directive" /> 1373 1381 <t> 1374 The only-if-cached request directive indicates that the client only 1375 wishes to obtain a stored response. If it receives 3ive, a1376 cache &SHOULD; either respond using a stored response that is consistent1377 with the other constraints of the request, or respond with a <x:ref>5041378 (Gateway Timeout)</x:ref> status code. If a group of caches is being operated as1379 aunified system with good internal connectivity, a member cache &MAY;1382 The only-if-cached request directive indicates that the client only wishes 1383 to obtain a stored response. If it receives 3ive, a cache &SHOULD; either 1384 respond using a stored response that is consistent with the other 1385 constraints of the request, or respond with a <x:ref>504 (Gateway 1386 Timeout)</x:ref> status code. If a group of caches is being operated as a 1387 unified system with good internal connectivity, a member cache &MAY; 1380 1388 forward such a request within that group of caches. 1381 1389 </t> … … 1433 1441 </t> 1434 1442 <t> 1435 &Note; This directive uses the quoted-string form of the argument 1436 syntax. Senders &SHOULD-NOT; use the token form (even if quoting appears not1437 to beneeded for single-entry lists).1443 &Note; This directive uses the quoted-string form of the argument syntax. 1444 Senders &SHOULD-NOT; use the token form (even if quoting appears not to be 1445 needed for single-entry lists). 1438 1446 </t> 1439 1447 </section> … … 1479 1487 </t> 1480 1488 <t> 1481 &Note; This directive uses the quoted-string form of the argument 1482 syntax. Senders &SHOULD-NOT; use the token form (even if quoting appears not1483 to beneeded for single-entry lists).1489 &Note; This directive uses the quoted-string form of the argument syntax. 1490 Senders &SHOULD-NOT; use the token form (even if quoting appears not to be 1491 needed for single-entry lists). 1484 1492 </t> 1485 1493 </section> … … 1914 1922 </t> 1915 1923 <t> 1916 If an implementation sends a message with one or more Warning header fields to a1917 receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include1918 in each warning-value a warn-date that matches the <x:ref>Date</x:ref> header1919 field in the message.1920 </t> 1921 <t> 1922 If a system receives a message with a warning-value that includes 1923 awarn-date, and that warn-date is different from the <x:ref>Date</x:ref>1924 If an implementation sends a message with one or more Warning header fields 1925 to a receiver whose version is HTTP/1.0 or lower, then the sender &MUST; 1926 include in each warning-value a warn-date that matches the 1927 <x:ref>Date</x:ref> header field in the message. 1928 </t> 1929 <t> 1930 If a system receives a message with a warning-value that includes a 1931 warn-date, and that warn-date is different from the <x:ref>Date</x:ref> 1924 1932 value in the response, then that warning-value &MUST; be deleted from the 1925 message before storing, forwarding, or using it. (preventing the consequences 1926 of naive caching of Warning header fields.) If all of the warning-values are 1927 deleted for this reason, the Warning header field &MUST; be deleted as well. 1933 message before storing, forwarding, or using it. (preventing the 1934 consequences of naive caching of Warning header fields.) If all of the 1935 warning-values are deleted for this reason, the Warning header field &MUST; 1936 be deleted as well. 1928 1937 </t> 1929 1938 <t>
Note: See TracChangeset
for help on using the changeset viewer.