Changeset 1858 for draft-ietf-httpbis
- Timestamp:
- 03/09/12 21:29:18 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1857 r1858 597 597 <li><a href="#rfc.section.3.4">3.4</a> <a href="#representation.data">Representation Data</a></li> 598 598 <li><a href="#rfc.section.3.5">3.5</a> <a href="#content.negotiation">Content Negotiation</a><ul> 599 <li><a href="#rfc.section.3.5.1">3.5.1</a> <a href="# server-driven.negotiation">Server-drivenNegotiation</a></li>600 <li><a href="#rfc.section.3.5.2">3.5.2</a> <a href="# agent-driven.negotiation">Agent-drivenNegotiation</a></li>599 <li><a href="#rfc.section.3.5.1">3.5.1</a> <a href="#proactive.negotiation">Proactive Negotiation</a></li> 600 <li><a href="#rfc.section.3.5.2">3.5.2</a> <a href="#reactive.negotiation">Reactive Negotiation</a></li> 601 601 </ul> 602 602 </li> … … 1118 1118 more than one is available. 1119 1119 </p> 1120 <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; " server-driven", where the server selects the representation1121 based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations1122 for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an1123 "active content" pattern, where the server returns active content which runs on the client and, based on client available1124 parameters,selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.1120 <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based 1121 upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for 1122 the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active 1123 content" pattern, where the server returns active content which runs on the client and, based on client available parameters, 1124 selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed. 1125 1125 </p> 1126 1126 <p id="rfc.section.3.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number 1127 1127 of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by 1128 a user-agent), server-drivennegotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations1129 to choose from is very large, agent-drivennegotiation might not be appropriate.1128 a user-agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations 1129 to choose from is very large, reactive negotiation might not be appropriate. 1130 1130 </p> 1131 1131 <p id="rfc.section.3.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might 1132 1132 be considered to be the "same information". 1133 1133 </p> 1134 <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a> <a id=" server-driven.negotiation" href="#server-driven.negotiation">Server-drivenNegotiation</a></h3>1135 <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven1134 <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a> <a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3> 1135 <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive 1136 1136 negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g., 1137 1137 language, content-coding, etc.) and the contents of particular header fields in the request message or on other information 1138 1138 pertaining to the request (such as the network address of the client). 1139 1139 </p> 1140 <p id="rfc.section.3.5.1.p.2"> Server-drivennegotiation is advantageous when the algorithm for selecting from among the available representations is difficult1140 <p id="rfc.section.3.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult 1141 1141 to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response 1142 1142 (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to 1143 1143 improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response. 1144 1144 </p> 1145 <p id="rfc.section.3.5.1.p.3"> Server-drivennegotiation has disadvantages: </p>1145 <p id="rfc.section.3.5.1.p.3">Proactive negotiation has disadvantages: </p> 1146 1146 <ol> 1147 1147 <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require … … 1155 1155 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 1156 1156 </ol> 1157 <p id="rfc.section.3.5.1.p.4"> Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor1158 them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response1159 thatdoesn't conform to them is better than sending a <a href="#status.406" class="smpl">4061157 <p id="rfc.section.3.5.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them. 1158 For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that 1159 doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406 1160 1160 (Not Acceptable)</a> response. 1161 1161 </p> 1162 <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling server-drivennegotiation through description of user agent capabilities1162 <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities 1163 1163 and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.3.2</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 6.3.4</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.3.5</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 6.5.3</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 1164 1164 within extension header fields not defined by this specification. … … 1168 1168 </p> 1169 1169 </div> 1170 <p id="rfc.section.3.5.1.p.7">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-drivennegotiation.1171 </p> 1172 <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a> <a id=" agent-driven.negotiation" href="#agent-driven.negotiation">Agent-drivenNegotiation</a></h3>1173 <p id="rfc.section.3.5.2.p.1">With agent-drivennegotiation, selection of the best representation for a response is performed by the user agent after receiving1170 <p id="rfc.section.3.5.1.p.7">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation. 1171 </p> 1172 <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a> <a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3> 1173 <p id="rfc.section.3.5.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving 1174 1174 an initial response from the origin server. Selection is based on a list of the available representations of the response 1175 1175 included within the header fields or body of the initial response, with each representation identified by its own URI. Selection … … 1177 1177 user selecting from a generated (possibly hypertext) menu. 1178 1178 </p> 1179 <p id="rfc.section.3.5.2.p.2"> Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,1180 orencoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally1179 <p id="rfc.section.3.5.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or 1180 encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally 1181 1181 when public caches are used to distribute server load and reduce network usage. 1182 1182 </p> 1183 <p id="rfc.section.3.5.2.p.3"> Agent-drivennegotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.1183 <p id="rfc.section.3.5.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. 1184 1184 This second request is only efficient when caching is used. In addition, this specification does not define any mechanism 1185 1185 for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension 1186 1186 and used within HTTP/1.1. 1187 1187 </p> 1188 <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-drivennegotiation when the server is unwilling or unable to provide a varying response using1189 server-drivennegotiation.1188 <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using 1189 proactive negotiation. 1190 1190 </p> 1191 1191 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="payload" href="#payload">Payload</a></h1> … … 1714 1714 </div> 1715 1715 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1716 <p id="rfc.section.6.3.1.p.1">Many of the request header fields for server-drivencontent negotiation use a common parameter, named "q", to assign a relative1716 <p id="rfc.section.6.3.1.p.1">Many of the request header fields for proactive content negotiation use a common parameter, named "q", to assign a relative 1717 1717 "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue") 1718 1718 because the same parameter name is often used within server configurations to assign a weight to the relative quality of the … … 2417 2417 </li> 2418 2418 <li> 2419 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-drivenNegotiation">Section 3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.2419 <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section 3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>. 2420 2420 </p> 2421 2421 </li> … … 2446 2446 <div id="rfc.iref.s.14"></div> 2447 2447 <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 2448 <p id="rfc.section.7.4.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-drivennegotiation information2448 <p id="rfc.section.7.4.1.p.1">The target resource has more than one representation, each with its own specific location, and reactive negotiation information 2449 2449 (<a href="#content.negotiation" title="Content Negotiation">Section 3.5</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 2450 2450 location. -
draft-ietf-httpbis/latest/p2-semantics.xml
r1857 r1858 27 27 <!ENTITY auth "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 28 <!ENTITY content-negotiation "<xref target='content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 <!ENTITY agent-driven-negotiation "<xref target='agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">29 <!ENTITY reactive-negotiation "<xref target='reactive.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 30 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 31 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 703 703 <t> 704 704 This specification defines two patterns of content negotiation; 705 " server-driven", where the server selects the representation based706 upon the client's stated preferences, and " agent-driven" negotiation,705 "proactive", where the server selects the representation based 706 upon the client's stated preferences, and "reactive" negotiation, 707 707 where the server provides a list of representations for the client to 708 708 choose from, based upon their metadata. In addition, there are … … 717 717 and practicality. In particular, when the number of preferences or 718 718 capabilities to be expressed by a client are large (such as when many 719 different formats are supported by a user-agent), server-driven719 different formats are supported by a user-agent), proactive 720 720 negotiation becomes unwieldy, and might not be appropriate. Conversely, 721 721 when the number of representations to choose from is very large, 722 agent-drivennegotiation might not be appropriate.722 reactive negotiation might not be appropriate. 723 723 </t> 724 724 <t> … … 728 728 </t> 729 729 730 <section title=" Server-driven Negotiation" anchor="server-driven.negotiation">730 <section title="Proactive Negotiation" anchor="proactive.negotiation"> 731 731 <t> 732 732 If the selection of the best representation for a response is made by 733 an algorithm located at the server, it is called server-driven733 an algorithm located at the server, it is called proactive 734 734 negotiation. Selection is based on the available representations of 735 735 the response (the dimensions over which it can vary; e.g., language, … … 739 739 </t> 740 740 <t> 741 Server-drivennegotiation is advantageous when the algorithm for741 Proactive negotiation is advantageous when the algorithm for 742 742 selecting from among the available representations is difficult to 743 743 describe to the user agent, or when the server desires to send its … … 750 750 </t> 751 751 <t> 752 Server-drivennegotiation has disadvantages:752 Proactive negotiation has disadvantages: 753 753 <list style="numbers"> 754 754 <t> … … 776 776 </t> 777 777 <t> 778 Server-drivennegotiation allows the user agent to specify its preferences,778 Proactive negotiation allows the user agent to specify its preferences, 779 779 but it cannot expect responses to always honor them. For example, the origin 780 server might not implement server-drivennegotiation, or it might decide that780 server might not implement proactive negotiation, or it might decide that 781 781 sending a response that doesn't conform to them is better than sending a <x:ref>406 782 782 (Not Acceptable)</x:ref> response. … … 784 784 <t> 785 785 HTTP/1.1 includes the following header fields for enabling 786 server-drivennegotiation through description of user agent786 proactive negotiation through description of user agent 787 787 capabilities and user preferences: <x:ref>Accept</x:ref> 788 788 (<xref target="header.accept"/>), <x:ref>Accept-Charset</x:ref> … … 805 805 The <x:ref>Vary</x:ref> header field (&header-vary;) can be used to express 806 806 the parameters the server uses to select a representation that is subject to 807 server-drivennegotiation.808 </t> 809 </section> 810 811 <section title=" Agent-driven Negotiation" anchor="agent-driven.negotiation">812 <t> 813 With agent-drivennegotiation, selection of the best representation807 proactive negotiation. 808 </t> 809 </section> 810 811 <section title="Reactive Negotiation" anchor="reactive.negotiation"> 812 <t> 813 With reactive negotiation, selection of the best representation 814 814 for a response is performed by the user agent after receiving an 815 815 initial response from the origin server. Selection is based on a list … … 822 822 </t> 823 823 <t> 824 Agent-drivennegotiation is advantageous when the response would vary824 Reactive negotiation is advantageous when the response would vary 825 825 over commonly-used dimensions (such as type, language, or encoding), 826 826 when the origin server is unable to determine a user agent's … … 829 829 </t> 830 830 <t> 831 Agent-drivennegotiation suffers from the disadvantage of needing a831 Reactive negotiation suffers from the disadvantage of needing a 832 832 second request to obtain the best alternate representation. This 833 833 second request is only efficient when caching is used. In addition, … … 839 839 <t> 840 840 This specification defines the <x:ref>300 (Multiple Choices)</x:ref> and 841 <x:ref>406 (Not Acceptable)</x:ref> status codes for enabling agent-driven841 <x:ref>406 (Not Acceptable)</x:ref> status codes for enabling reactive 842 842 negotiation when the server is unwilling or unable to provide a varying 843 response using server-drivennegotiation.843 response using proactive negotiation. 844 844 </t> 845 845 </section> … … 1710 1710 <x:anchor-alias value="qvalue"/> 1711 1711 <t> 1712 Many of the request header fields for server-drivencontent negotiation1712 Many of the request header fields for proactive content negotiation 1713 1713 use a common parameter, named "q", to assign a relative "weight" to the 1714 1714 preference for that associated kind of content. … … 2593 2593 <t> 2594 2594 Redirection offering a choice of matching resources for use by 2595 agent-driven content negotiation (&agent-driven-negotiation;). This2595 reactive content negotiation (&reactive-negotiation;). This 2596 2596 is status code <x:ref>300 (Multiple Choices)</x:ref>. 2597 2597 </t> … … 2652 2652 <t> 2653 2653 The target resource has more than one 2654 representation, each with its own specific location, and agent-driven2654 representation, each with its own specific location, and reactive 2655 2655 negotiation information (&content-negotiation;) is being provided so that 2656 2656 the user (or user agent) can select a preferred representation by -
draft-ietf-httpbis/latest/p6-cache.html
r1845 r1858 452 452 } 453 453 @bottom-center { 454 content: "Expires March 5, 2013";454 content: "Expires March 7, 2013"; 455 455 } 456 456 @bottom-right { … … 499 499 <meta name="dct.creator" content="Reschke, J. F."> 500 500 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 501 <meta name="dct.issued" scheme="ISO8601" content="2012-09-0 1">501 <meta name="dct.issued" scheme="ISO8601" content="2012-09-03"> 502 502 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 503 503 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: March 5, 2013</td>527 <td class="left">Expires: March 7, 2013</td> 528 528 <td class="right">M. Nottingham, Editor</td> 529 529 </tr> … … 542 542 <tr> 543 543 <td class="left"></td> 544 <td class="right">September 1, 2012</td>544 <td class="right">September 3, 2012</td> 545 545 </tr> 546 546 </tbody> … … 568 568 in progress”. 569 569 </p> 570 <p>This Internet-Draft will expire on March 5, 2013.</p>570 <p>This Internet-Draft will expire on March 7, 2013.</p> 571 571 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 572 572 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 912 912 <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>. 913 913 </p> 914 <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request914 <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request 915 915 and having received a corresponding response. 916 916 </p> … … 966 966 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3> 967 967 <p id="rfc.section.4.1.2.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness 968 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial968 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial 969 969 Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved 970 970 Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it. … … 999 999 <ul class="empty"> 1000 1000 <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value" 1001 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.1001 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 1002 1002 </li> 1003 1003 </ul> … … 1181 1181 </ul> 1182 1182 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1> 1183 <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them1183 <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 1184 1184 to keep their contents up-to-date. 1185 1185 </p> … … 1468 1468 that time. 1469 1469 </p> 1470 <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.1470 <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format. 1471 1471 </p> 1472 1472 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a> … … 1530 1530 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.vary" class="smpl">Vary</a> = "*" / 1#<a href="#imported.abnf" class="smpl">field-name</a> 1531 1531 </pre><p id="rfc.section.7.5.p.5">The set of header fields named by the Vary field value is known as the selecting header fields.</p> 1532 <p id="rfc.section.7.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-drivennegotiation. Doing so allows a cache1532 <p id="rfc.section.7.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to proactive negotiation. Doing so allows a cache 1533 1533 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that 1534 resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-drivennegotiation, since this might provide1534 resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to proactive negotiation, since this might provide 1535 1535 the user agent with useful information about the dimensions over which the response varies at the time of the response. 1536 1536 </p> … … 1988 1988 <a href="#imported.abnf" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 1989 1989 </pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p> 1990 <div id="rfc.figure.u.16"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a>>1990 <div id="rfc.figure.u.16"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>> 1991 1991 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1992 1992 <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds … … 2220 2220 </li> 2221 2221 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">4.1.3</a>, <a href="#rfc.xref.Part2.5">6</a>, <a href="#rfc.xref.Part2.6">7.3</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.7">B</a><ul> 2222 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.5">6</a></li>2223 <li><em>Section 5</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li>2224 <li><em>Section 6.1</em> <a href="#rfc.xref.Part2.6">7.3</a>, <a href="#rfc.xref.Part2.7">B</a></li>2225 <li><em>Section 10.10</em> <a href="#rfc.xref.Part2.4">4.1.3</a></li>2222 <li><em>Section 5.2.1</em> <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.5">6</a></li> 2223 <li><em>Section 7</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li> 2224 <li><em>Section 8.2.1</em> <a href="#rfc.xref.Part2.4">4.1.3</a></li> 2225 <li><em>Section 9.1</em> <a href="#rfc.xref.Part2.6">7.3</a>, <a href="#rfc.xref.Part2.7">B</a></li> 2226 2226 </ul> 2227 2227 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r1845 r1858 1795 1795 <t> 1796 1796 A server &SHOULD; include a Vary header field with any cacheable response 1797 that is subject to server-drivennegotiation. Doing so allows a cache to1797 that is subject to proactive negotiation. Doing so allows a cache to 1798 1798 properly interpret future requests on that resource and informs the user 1799 1799 agent about the presence of negotiation on that resource. A server &MAY; 1800 1800 include a Vary header field with a non-cacheable response that is subject 1801 to server-drivennegotiation, since this might provide the user agent with1801 to proactive negotiation, since this might provide the user agent with 1802 1802 useful information about the dimensions over which the response varies at 1803 1803 the time of the response.
Note: See TracChangeset
for help on using the changeset viewer.