Changeset 606 for draft-ietf-httpbis/07
- Timestamp:
- 13/07/09 02:56:55 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/07/p6-cache.xml
r604 r606 33 33 <!ENTITY safe-methods "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 34 <!ENTITY server-driven-negotiation "<xref target='Part3' x:rel='#server-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 <!ENTITY weak-and-strong "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 36 ]> 36 37 <?rfc toc="yes" ?> … … 718 719 <section anchor="validation.model" title="Validation Model"> 719 720 <t> 720 Checking with the origin server to see if a stale or otherwise unusable cached response 721 can be reused is called "validating" or "revalidating." Doing so potentially avoids 722 the overhead of retransmitting the response body when the stored response is valid. 723 </t> 724 <t> 725 HTTP's conditional request mechanism &conditional; is used for this purpose. When a stored 726 response includes one or more validators, such as the field values of an ETag or 727 Last-Modified header field, then a validating request &SHOULD; be made conditional 728 to those field values. 721 When a cache has one or more stored responses for a requested URI, but cannot 722 serve any of them (e.g., because they are not fresh, or one cannot be selected; 723 see <xref target="caching.negotiated.responses"/>), 724 it can use the conditional request mechanism &conditional; in the forwarded 725 request to give the origin server an opportunity to both select a valid stored 726 response to be used, and to update it. This process is known as "validating" 727 or "revalidating" the stored response. 728 </t> 729 <t> 730 When sending such a conditional request, the cache &SHOULD; add an If-Modified-Since 731 header whose value is that of the Last-Modified header from the selected 732 (see <xref target="caching.negotiated.responses"/>) stored response, if available. 733 </t> 734 <t> 735 Additionally, the cache &SHOULD; add an If-None-Match header whose value 736 is that of the ETag header(s) from all responses stored for the requested URI, 737 if present. However, if any of the stored responses contains only partial 738 content, its entity-tag &SHOULD-NOT; be included in the If-None-Match header 739 field unless the request is for a range that would be fully satisfied by 740 that stored response. 729 741 </t> 730 742 <t> … … 733 745 </t> 734 746 <t> 735 If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the 736 request and replace the stored response. <cref>Should there be a requirement here?</cref> 747 A full response (i.e., one with a response body) indicates that none 748 of the stored responses nominated in the conditional request is 749 suitable. Instead, the full response is used both to satisfy the 750 request and replace the stored response. <cref>Should there be a requirement here?</cref> 737 751 </t> 738 752 <t> 739 753 If a cache receives a 5xx response while attempting to validate a response, it &MAY; 740 754 either forward this response to the requesting client, or act as if the server failed to 741 respond. In the latter case, it &MAY; return a previously stored response (which &SHOULD; include the 742 111 warn-code; see <xref target="header.warning"/>) unless the 743 stored response includes the "must-revalidate" cache directive (see <xref 755 respond. In the latter case, it &MAY; return a previously stored response (see <xref 744 756 target="serving.stale.responses" />). 757 </t> 758 <t> 759 If a cache receives a successful response whose Content-Location field 760 matches that of an existing stored response for the same Request-URI, 761 whose entity-tag differs from that of the existing stored response, 762 and whose Date is more recent than that of the existing response, the 763 existing response &SHOULD-NOT; be returned in response to future 764 requests and &SHOULD; be deleted from the cache. <cref>DISCUSS: Not 765 sure if this is necessary.</cref> 745 766 </t> 746 767 </section> … … 790 811 <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses"> 791 812 <t> 792 Use of server-driven content negotiation (&server-driven-negotiation;) alters793 the conditions under which a cache can use the response for subsequent794 requests.795 </t>796 <t>797 813 When a cache receives a request that can be satisfied by a stored response 798 that includes a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; use that response unless 799 all of the selecting request-headers in the presented request match the corresponding 800 stored request-headers from the original request. 814 that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; use that 815 response unless all of the selecting request-headers nominated by the Vary header match 816 in both the original request (i.e., that associated with the stored response), 817 and the presented request. 801 818 </t> 802 819 <t> … … 806 823 <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 807 824 combining multiple message-header fields with the same field name following the rules 808 about message headers in &message-headers;. <cref anchor="DISCUSS-header-specific-canonicalization">809 Should the matching requirement be relaxed so that it would be ok to use a cached response 810 if the selecting request headers match after header-specific canonicalization? 811 (see <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</eref>) 812 </cref> 825 about message headers in &message-headers;. 826 </t> 827 <t> 828 If a header field is absent from a request, it can only match another request 829 if it is also absent there. 813 830 </t> 814 831 <t> … … 816 833 resource can only be properly interpreted by the origin server. 817 834 </t> 818 <t> 819 If no stored response matches, the cache &MAY; forward the presented request to the origin 820 server in a conditional request, and &SHOULD; include all ETags stored with 821 potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and 822 includes an entity tag or Content-Location that indicates the entity to be used, that 823 cached response &MUST; be used to satisfy the presented request, and &SHOULD; 824 be used to update the corresponding stored response; see <xref target="combining.headers"/>. 825 </t> 826 <t> 827 If any of the stored responses contains only partial content, its entity-tag &SHOULD-NOT; 828 be included in the If-None-Match header field unless the request is for a range that would 829 be fully satisfied by that stored response. 830 </t> 831 <t> 832 If a cache receives a successful response whose Content-Location field matches that of an 833 existing stored response for the same Request-URI, whose entity-tag differs from that of 834 the existing stored response, and whose Date is more recent than that of the existing 835 response, the existing response &SHOULD-NOT; be returned in response to future 836 requests and &SHOULD; be deleted from the cache.<cref>DISCUSS: Not sure if this is necessary.</cref> 835 <t>The stored response with matching selecting request-headers is known as the 836 selected response. 837 </t> 838 <t> 839 If no selected response is available, the cache &MAY; forward the presented 840 request to the origin server in a conditional request; see <xref target="validation.model"/>. 837 841 </t> 838 842 </section> … … 840 844 <section anchor="combining.headers" title="Combining Responses"> 841 845 <t> 842 When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, 843 it needs to update the stored response with the new one, so that the updated response can 844 be sent to the client. 845 </t> 846 <t> 847 If the status code is 304 (Not Modified), the cache &SHOULD; use the stored entity-body as 848 the updated entity-body. If the status code is 206 (Partial Content) and the ETag or 849 Last-Modified headers match exactly, the cache &MAY; combine the stored entity-body in 850 the stored response with the updated entity-body received in the response and use the 851 result as the updated entity-body (see &combining-byte-ranges;). 852 </t> 853 <t> 854 The stored response headers are used for the updated response, except that 846 When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response 847 (in this section, the "new" response"), it needs to created an updated response by combining 848 the stored response with the new one, so that the updated response can be used to satisfy the request. 849 </t> 850 <t> 851 If the new response contains an ETag, it identifies the stored 852 response to use. <cref>may need language about Content-Location 853 here</cref><cref>cover case where INM with multiple etags was sent</cref> 854 </t> 855 <t> 856 If the status code is 206 (partial content), both the stored and new 857 responses &MUST; have ETags, and those ETags &MUST; match using the strong 858 comparison function (see &weak-and-strong;). Otherwise, the 859 responses &MUST-NOT; be combined. 860 </t> 861 <t> 862 The stored response headers are used as those of the updated response, except that 855 863 <list style="symbols"> 856 864 <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning" />) 857 &MUST; be deleted from the stored response and the forwarded response.</t>865 &MUST; be deleted from the stored response and the updated response.</t> 858 866 <t>any stored Warning headers with warn-code 2xx &MUST; be retained in the stored 859 response and the forwarded response.</t>860 <t>any headers provided in the 304 or 206response &MUST; replace the corresponding867 response and the updated response.</t> 868 <t>any headers provided in the new response &MUST; replace the corresponding 861 869 headers from the stored response.</t> 862 870 </list> 863 871 </t> 864 872 <t> 865 A cache &MUST; also replace any stored headers with corresponding headers received in the 866 incoming response, except for Warning headers as described immediately above. If a header 867 field-name in the incoming response matches more than one header in the stored response, 868 all such old headers &MUST; be replaced. It &MAY; store the combined 869 entity-body. 873 If a header field-name in the new response matches more than one 874 header in the stored response, all such stored headers &MUST; be replaced. 875 </t> 876 <t> 877 The updated response can [[<cref>requirement?</cref>]] be used to replace the 878 stored response in cache. In the case of a 206 response, the combined 879 entity-body &MAY; be stored. 870 880 </t> 871 881 <t> … … 2324 2334 </list> 2325 2335 </t> 2336 <t> 2337 Affected issues: 2338 <list style="symbols"> 2339 <t> 2340 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>: 2341 Vary and non-existant headers 2342 </t> 2343 </list> 2344 </t> 2326 2345 </section> 2327 2346
Note: See TracChangeset
for help on using the changeset viewer.