Changeset 994 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 07/09/10 11:46:12 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r981 r994 439 439 <t>the "no-store" cache directive (see <xref 440 440 target="header.cache-control" />) does not appear in request or response 441 header s, and</t>441 header fields, and</t> 442 442 <t>the "private" cache response directive (see <xref 443 443 target="cache-response-directive" /> does not appear in the response, if 444 444 the cache is shared, and</t> 445 <t>the "Authorization" header (see &header-authorization;) does not445 <t>the "Authorization" header field (see &header-authorization;) does not 446 446 appear in the request, if the cache is shared, unless the response 447 447 explicitly allows it (see <xref target="caching.authenticated.responses" … … 449 449 <t>the response either: 450 450 <list style="symbols"> 451 <t>contains an Expires header (see <xref target="header.expires"451 <t>contains an Expires header field (see <xref target="header.expires" 452 452 />), or</t> 453 453 <t>contains a max-age response cache directive (see <xref … … 482 482 <t> 483 483 A cache that receives an incomplete response (for example, with fewer bytes 484 of data than specified in a Content-Length header ) can store the response,484 of data than specified in a Content-Length header field) can store the response, 485 485 but &MUST; treat it as a partial response &partial;. Partial responses can 486 486 be combined as described in &combining-byte-ranges;; the result might be a … … 490 490 </t> 491 491 <t> 492 A cache that does not support the Range and Content-Range header s492 A cache that does not support the Range and Content-Range header fields 493 493 &MUST-NOT; store incomplete or partial responses. 494 494 </t> … … 508 508 <t>the request method associated with the stored response allows it to 509 509 be used for the presented request, and</t> 510 <t>selecting request-header s nominated by the stored response (if any)510 <t>selecting request-header fields nominated by the stored response (if any) 511 511 match those presented (see <xref target="caching.negotiated.responses" 512 512 />), and</t> … … 543 543 <t> 544 544 Caches &MUST; use the most recent response (as determined by the Date 545 header ) when more than one suitable response is stored. They can also545 header field) when more than one suitable response is stored. They can also 546 546 forward a request with "Cache-Control: max-age=0" or "Cache-Control: 547 547 no-cache" to disambiguate which response to use. … … 558 558 The primary mechanism for determining freshness is for an origin server to 559 559 provide an explicit expiration time in the future, using either the Expires 560 header (<xref target="header.expires" />) or the max-age response cache560 header field (<xref target="header.expires" />) or the max-age response cache 561 561 directive (<xref target="cache-response-directive" />). Generally, origin 562 562 servers will assign future explicit expiration times to responses in the … … 573 573 Since origin servers do not always provide explicit expiration times, HTTP 574 574 caches &MAY; assign heuristic expiration times when explicit times are not 575 specified, employing algorithms that use other heade rvalues (such as the575 specified, employing algorithms that use other heade field values (such as the 576 576 Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 577 577 specification does not provide specific algorithms, but does impose … … 619 619 <t>If the max-age response cache directive (<xref 620 620 target="cache-response-directive" />) is present, use its value, or</t> 621 <t>If the Expires response header (<xref target="header.expires" />) is622 present, use its value minus the value of the Date response header ,621 <t>If the Expires response header field (<xref target="header.expires" />) is 622 present, use its value minus the value of the Date response header field, 623 623 or</t> 624 624 <t>Otherwise, no explicit expiration time is present in the response. A … … 643 643 <t> 644 644 When a heuristic is used to calculate freshness lifetime, the cache 645 &SHOULD; attach a Warning header with a 113 warn-code to the response if645 &SHOULD; attach a Warning header field with a 113 warn-code to the response if 646 646 its current_age is more than 24 hours and such a warning is not already 647 647 present. 648 648 </t> 649 649 <t> 650 Also, if the response has a Last-Modified header (&header-last-modified;),650 Also, if the response has a Last-Modified header field (&header-last-modified;), 651 651 the heuristic expiration value &SHOULD; be no more than some fraction of 652 652 the interval since that time. A typical setting of this fraction might be … … 668 668 <section anchor="age.calculations" title="Calculating Age"> 669 669 <t> 670 HTTP/1.1 uses the Age response-header to convey the estimated age of the670 HTTP/1.1 uses the Age response-header field to convey the estimated age of the 671 671 response message when obtained from a cache. The Age field value is the 672 672 cache's estimate of the amount of time since the response was generated or … … 683 683 <list> 684 684 <t> 685 The term "age_value" denotes the value of the Age header (<xref685 The term "age_value" denotes the value of the Age header field (<xref 686 686 target="header.age"/>), in a form appropriate for arithmetic 687 687 operation; or 0, if not available. … … 693 693 <list> 694 694 <t> 695 HTTP/1.1 requires origin servers to send a Date header , if possible,695 HTTP/1.1 requires origin servers to send a Date header field, if possible, 696 696 with every response, giving the time at which the response was 697 697 generated. The term "date_value" denotes the value of the Date 698 header , in a form appropriate for arithmetic operations. See699 &header-date; for the definition of the Date header , and for700 requirements regarding responses without a Date response header.698 header field, in a form appropriate for arithmetic operations. See 699 &header-date; for the definition of the Date header field, and for 700 requirements regarding responses without it. 701 701 </t> 702 702 </list> … … 788 788 </t> 789 789 <t> 790 Stale responses &SHOULD; have a Warning header with the 110 warn-code (see790 Stale responses &SHOULD; have a Warning header field with the 110 warn-code (see 791 791 <xref target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be 792 792 sent on stale responses if the cache is disconnected. … … 797 797 requesting client, and the received response is no longer fresh, the cache 798 798 &SHOULD; forward it to the requesting client without adding a new Warning 799 (but without removing any existing Warning header s). A cache &SHOULD-NOT;799 (but without removing any existing Warning header fields). A cache &SHOULD-NOT; 800 800 attempt to validate a response simply because that response became stale in 801 801 transit. … … 816 816 <t> 817 817 When sending such a conditional request, the cache &SHOULD; add an 818 If-Modified-Since header whose value is that of the Last-Modified header819 f rom the selected (see <xref target="caching.negotiated.responses"/>)818 If-Modified-Since header field whose value is that of the Last-Modified header 819 field from the selected (see <xref target="caching.negotiated.responses"/>) 820 820 stored response, if available. 821 821 </t> 822 822 <t> 823 Additionally, the cache &SHOULD; add an If-None-Match header whose value is824 that of the ETag header (s) from all responses stored for the requested URI,823 Additionally, the cache &SHOULD; add an If-None-Match header field whose value is 824 that of the ETag header field(s) from all responses stored for the requested URI, 825 825 if present. However, if any of the stored responses contains only partial 826 826 content, its entity-tag &SHOULD-NOT; be included in the If-None-Match … … 830 830 <t> 831 831 A 304 (Not Modified) response status code indicates that the stored 832 response can be updated and reused; see <xref target="combining. headers"/>.832 response can be updated and reused; see <xref target="combining.responses"/>. 833 833 </t> 834 834 <t> … … 856 856 The following HTTP methods &MUST; cause a cache to invalidate the effective 857 857 Request URI (&effective-request-uri;) as well as the URI(s) in the Location 858 and Content-Location header s (if present):858 and Content-Location header fields (if present): 859 859 <list style="symbols"> 860 860 <t>PUT</t> … … 864 864 </t> 865 865 <t> 866 An invalidation based on a URI from a Location or Content-Location header 866 An invalidation based on a URI from a Location or Content-Location header field 867 867 &MUST-NOT; be performed if the host part of that URI differs from the host 868 868 part in the effective request URI (&effective-request-uri;). This helps … … 891 891 <t> 892 892 Shared caches &MUST-NOT; use a cached response to a request with an 893 Authorization header (&header-authorization;) to satisfy any subsequent893 Authorization header field (&header-authorization;) to satisfy any subsequent 894 894 request unless a cache directive that allows such responses to be stored is 895 895 present in the response. … … 917 917 When a cache receives a request that can be satisfied by a stored response 918 918 that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; 919 use that response unless all of the selecting request-header s nominated by920 the Vary header match in both the original request (i.e., that associated919 use that response unless all of the selecting request-header fields nominated by 920 the Vary header field match in both the original request (i.e., that associated 921 921 with the stored response), and the presented request. 922 922 </t> 923 923 <t> 924 The selecting request-header s from two requests are defined to match if and924 The selecting request-header fields from two requests are defined to match if and 925 925 only if those in the first request can be transformed to those in the 926 926 second request by applying any of the following: 927 927 <list style="symbols"> 928 928 <t> 929 adding or removing whitespace, where allowed in the header 's syntax929 adding or removing whitespace, where allowed in the header field's syntax 930 930 </t> 931 931 <t> … … 934 934 </t> 935 935 <t> 936 normalizing both header values in a way that is known to have937 identical semantics, according to the header 's specification (e.g.,936 normalizing both header field values in a way that is known to have 937 identical semantics, according to the header field's specification (e.g., 938 938 re-ordering field values when order is not significant; 939 939 case-normalization, where values are defined to be case-insensitive) … … 952 952 </t> 953 953 <t> 954 The stored response with matching selecting request-header s is known as the954 The stored response with matching selecting request-header fields is known as the 955 955 selected response. 956 956 </t> … … 962 962 </section> 963 963 964 <section anchor="combining. headers" title="Combining Responses">964 <section anchor="combining.responses" title="Combining Responses"> 965 965 <t> 966 966 When a cache receives a 304 (Not Modified) response or a 206 (Partial … … 984 984 </t> 985 985 <t> 986 The stored response header s are used as those of the updated response,986 The stored response header fields are used as those of the updated response, 987 987 except that 988 988 <list style="symbols"> 989 <t>any stored Warning header s with warn-code 1xx (see <xref989 <t>any stored Warning header fields with warn-code 1xx (see <xref 990 990 target="header.warning" />) &MUST; be deleted.</t> 991 <t>any stored Warning header s with warn-code 2xx &MUST; be retained.</t>992 <t>any other header s provided in the new response &MUST; replace all993 instances of the corresponding header s from the stored response.</t>994 </list> 995 </t> 996 <t> 997 The updated response header s &MUST; be used to replace those of the stored991 <t>any stored Warning header fields with warn-code 2xx &MUST; be retained.</t> 992 <t>any other header fields provided in the new response &MUST; replace all 993 instances of the corresponding header fields from the stored response.</t> 994 </list> 995 </t> 996 <t> 997 The updated response header fields &MUST; be used to replace those of the stored 998 998 response in cache (unless the stored response is removed from cache). In 999 999 the case of a 206 response, the combined representation &MAY; be stored. … … 1035 1035 If a cache receives a value larger than the largest positive integer it can 1036 1036 represent, or if any of its age calculations overflows, it &MUST; transmit 1037 an Age header with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches1037 an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches 1038 1038 &SHOULD; use an arithmetic type of at least 31 bits of range. 1039 1039 </t> … … 1179 1179 <t>The no-transform request directive indicates that an intermediate 1180 1180 cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or 1181 Content-Type request header s, nor the request representation.</t>1181 Content-Type request header fields, nor the request representation.</t> 1182 1182 </list> 1183 1183 </t> … … 1238 1238 <t>If the private response directive specifies one or more field-names, 1239 1239 this requirement is limited to the field-values associated with the 1240 listed response header s. That is, the specified field-names(s)1240 listed response header fields. That is, the specified field-names(s) 1241 1241 &MUST-NOT; be stored by a shared cache, whereas the remainder of the 1242 1242 response message &MAY; be.</t> … … 1261 1261 <t>If the no-cache response directive specifies one or more field-names, 1262 1262 this requirement is limited to the field-values associated with the 1263 listed response header s. That is, the specified field-name(s) &MUST-NOT;1263 listed response header fields. That is, the specified field-name(s) &MUST-NOT; 1264 1264 be sent in the response to a subsequent request without successful 1265 1265 validation on the origin server. This allows an origin server to prevent … … 1337 1337 <t>The s-maxage response directive indicates that, in shared caches, the 1338 1338 maximum age specified by this directive overrides the maximum age 1339 specified by either the max-age directive or the Expires header . The1339 specified by either the max-age directive or the Expires header field. The 1340 1340 s-maxage directive also implies the semantics of the proxy-revalidate 1341 1341 response directive.</t> … … 1349 1349 <t>The no-transform response directive indicates that an intermediate 1350 1350 cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or 1351 Content-Type response header s, nor the response representation.</t>1351 Content-Type response header fields, nor the response representation.</t> 1352 1352 </list> 1353 1353 </t> … … 1540 1540 <t> 1541 1541 The set of header fields named by the Vary field value is known as the 1542 selecting request-header s.1542 selecting request-header fields. 1543 1543 </t> 1544 1544 <t> … … 1554 1554 <t> 1555 1555 A Vary field value of "*" signals that unspecified parameters not limited 1556 to the request-header s (e.g., the network address of the client), play a1556 to the request-header fields (e.g., the network address of the client), play a 1557 1557 role in the selection of the response representation; therefore, a cache 1558 1558 cannot determine whether this response is appropriate. The "*" value … … 1588 1588 </t> 1589 1589 <t> 1590 Warning header s can in general be applied to any message, however some1590 Warning header fields can in general be applied to any message, however some 1591 1591 warn-codes are specific to caches and can only be applied to response 1592 1592 messages. … … 1602 1602 <x:ref>warn-agent</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref> 1603 1603 ; the name or pseudonym of the server adding 1604 ; the Warning header , for use in debugging1604 ; the Warning header field, for use in debugging 1605 1605 <x:ref>warn-text</x:ref> = <x:ref>quoted-string</x:ref> 1606 1606 <x:ref>warn-date</x:ref> = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref> … … 1616 1616 </t> 1617 1617 <t> 1618 Systems that generate multiple Warning header s &SHOULD; order them with1619 this user agent behavior in mind. New Warning header s &SHOULD; be added1620 after any existing Warning headers .1618 Systems that generate multiple Warning header fields &SHOULD; order them with 1619 this user agent behavior in mind. New Warning header fields &SHOULD; be added 1620 after any existing Warning headers fields. 1621 1621 </t> 1622 1622 <t> … … 1636 1636 </t> 1637 1637 <t> 1638 If an implementation sends a message with one or more Warning header s to a1638 If an implementation sends a message with one or more Warning header fields to a 1639 1639 receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include 1640 in each warning-value a warn-date that matches the Date header in the1640 in each warning-value a warn-date that matches the Date header field in the 1641 1641 message. 1642 1642 </t> … … 1647 1647 storing, forwarding, or using it. (preventing the consequences of naive 1648 1648 caching of Warning header fields.) If all of the warning-values are deleted 1649 for this reason, the Warning header &MUST; be deleted as well.1649 for this reason, the Warning header field &MUST; be deleted as well. 1650 1650 </t> 1651 1651 <t> … … 2274 2274 </t> 2275 2275 <t> 2276 Do not mention RFC 2047 encoding and multiple languages in Warning header s2276 Do not mention RFC 2047 encoding and multiple languages in Warning header fields 2277 2277 anymore, as these aspects never were implemented. 2278 2278 (<xref target="header.warning" />) … … 2417 2417 <section anchor="changes.since.02" title="Since draft-ietf-httpbis-p6-cache-02"> 2418 2418 <t> 2419 Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />):2419 Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />): 2420 2420 <list style="symbols"> 2421 <t>Reference RFC 3984, and update header registrations for headers defined in this2421 <t>Reference RFC 3984, and update header field registrations for header fields defined in this 2422 2422 document.</t> 2423 2423 </list> … … 2448 2448 <t> 2449 2449 Rewrite ABNFs to spell out whitespace rules, factor out 2450 header value format definitions.2450 header field value format definitions. 2451 2451 </t> 2452 2452 </list> … … 2496 2496 <t> 2497 2497 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>: 2498 Vary and non-existant headers2498 WVary and non-existant headers" 2499 2499 </t> 2500 2500 </list>
Note: See TracChangeset
for help on using the changeset viewer.