Changeset 607 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 13/07/09 06:55:38 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r604 r607 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" ?> … … 175 176 <author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham"> 176 177 <organization /> 177 <address> 178 <email>mnot@mnot.net</email> 179 <uri>http://www.mnot.net/</uri> 178 <address> 179 <email>mnot@mnot.net</email> 180 <uri>http://www.mnot.net/</uri> 180 181 </address> 181 182 </author> … … 189 190 <country>Germany</country> 190 191 </postal> 191 <phone>+49 251 2807760</phone> 192 <facsimile>+49 251 2807761</facsimile> 193 <email>julian.reschke@greenbytes.de</email> 194 <uri>http://greenbytes.de/tech/webdav/</uri> 192 <phone>+49 251 2807760</phone> 193 <facsimile>+49 251 2807761</facsimile> 194 <email>julian.reschke@greenbytes.de</email> 195 <uri>http://greenbytes.de/tech/webdav/</uri> 195 196 </address> 196 197 </author> … … 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 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 736 750 request and replace the stored response. <cref>Should there be a requirement here?</cref> 737 751 </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> … … 817 834 </t> 818 835 <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> 836 The stored response with matching selecting request-headers is known as the 837 selected response. 838 </t> 839 <t> 840 If no selected response is available, the cache &MAY; forward the presented 841 request to the origin server in a conditional request; see <xref target="validation.model"/>. 837 842 </t> 838 843 </section> … … 840 845 <section anchor="combining.headers" title="Combining Responses"> 841 846 <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 847 When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response 848 (in this section, the "new" response"), it needs to created an updated response by combining 849 the stored response with the new one, so that the updated response can be used to satisfy the request. 850 </t> 851 <t> 852 If the new response contains an ETag, it identifies the stored 853 response to use. <cref>may need language about Content-Location 854 here</cref><cref>cover case where INM with multiple etags was sent</cref> 855 </t> 856 <t> 857 If the status code is 206 (partial content), both the stored and new 858 responses &MUST; have ETags, and those ETags &MUST; match using the strong 859 comparison function (see &weak-and-strong;). Otherwise, the 860 responses &MUST-NOT; be combined. 861 </t> 862 <t> 863 The stored response headers are used as those of the updated response, except that 855 864 <list style="symbols"> 856 865 <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>866 &MUST; be deleted from the stored response and the updated response.</t> 858 867 <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 corresponding868 response and the updated response.</t> 869 <t>any headers provided in the new response &MUST; replace the corresponding 861 870 headers from the stored response.</t> 862 871 </list> 863 872 </t> 864 873 <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. 874 If a header field-name in the new response matches more than one 875 header in the stored response, all such stored headers &MUST; be replaced. 876 </t> 877 <t> 878 The updated response can [[<cref>requirement?</cref>]] be used to replace the 879 stored response in cache. In the case of a 206 response, the combined 880 entity-body &MAY; be stored. 870 881 </t> 871 882 <t> … … 2324 2335 </list> 2325 2336 </t> 2337 <t> 2338 Affected issues: 2339 <list style="symbols"> 2340 <t> 2341 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>: 2342 Vary and non-existant headers 2343 </t> 2344 </list> 2345 </t> 2326 2346 </section> 2327 2347
Note: See TracChangeset
for help on using the changeset viewer.